From amitabh.tiwari27 at gmail.com Wed Apr 1 08:44:24 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Wed, 1 Apr 2015 21:14:24 +0530 Subject: [GRASS-dev] Phase1 implemented:.C and Java codes for visual bands mining Message-ID: Hello everyone, I was working on this phase from January and finally I'am done with visual bands mining.The remaining two phases of my project: *Phase 2*: Infrared and Ultraviolet bands mining. *Phase 3*:Creation of UI for Customized area selections. *Phase 4*:Integration with GRASS GIS I'am hereby attaching my application: *Name:* Amitabh Tiwari *Country:* India *Email :* amitabh.tiwari27 at gmail.com *Phone :* 9969833570 *OSGeo Projects:* GRASS GIS *My proposal:* I propose to develop a software to mine RSI images' spectral bands including the visual,ultraviolet and infrared bands.This geospatial mining will be done at bit level of bands to ensure maximum accuracy.If you look at the products available in the market they offer predictions for the entire image instead I would allow users to choose customized areas to mine upon. *How this process would work?* *-->*This software can be used for multiple purposes like in case of Crop Yield production for farmers. *-->*The software would need an event(RSI Image of Crop Yield of a geographical region X) and a contributing factor i.e. a factor that contributes towards the success of the event like in this case it would be a RSI Image of rainfall of the same geographical region X. *-->*After the inputs are fed,then a multimedia data mining algorithm would find a kind of mapping between rainfall and crop yield. *-->*Once the mapping is found like Rainfall[ R<180,G>210,B<150 && B>125]-->Crop_yield[R>210,G>220,B<40] etc. then the farmer/user can enter "n" such rainfall RSI images of different geographical images and the yields over there can be predicted. *Demonstration :* I'am attaching a video of the functioning of codes that i have developed so far.These codes are used to mine only the visual bands of RSI images i.e Red,Green and Blue.I want to extend this process to mine Infrared and Ultraviolet bands and convert this collection of codes into a complete software product.Also these codes mine the entire images,rather i wish to build a GUI that would allow users to choose the areas of their concern in order to get high support and confidence rules. *Web application:* Once I was done with the development of codes.Then I thought of building the web application for my work and I uploaded the codes on the server side and then those were executed using shell scripting in PHP. *Versions of packages:* 1. RGB-->RGB (1 Event and 1 contributing factor) 2.RGB-->GREY (1 Event and 1 contributing factor) 3.RGB-->RGB (One Event and 3 contributing factor) *Explanation of Codes on GITHUB:* parm11.java-->Converts RSI images into Band Sequential Format. parm22.c-->Converts Band Sequential Format into bit Sequential Format. parm33.c-->Generates Itemsets and rules using Peano count Tree association rule mining algorithm. parm44.java-->Using rules and the input generates the predicted image. *Technical specifications : Java swings,C,PHP,HTML5,CSS3.* *Benefit to your organization:* It will basically add a new feature to GRASS GIS. Then your software will be powered by one of the most efficient and innovative geospatial data mining algorithm using which very accurate geospatial predictions can be made. *My Technical Skills:* *Programming languages:*Java,C,C++. *Database Connectivity:* PHP with MySQL. *Front end languages:* HTML,CSS,Javascript,VBScript. *Hardware : Linux Cluster.* *GIS and Open Source Projects:* I'ld be working with your organization for first time and would try my best that this bonding stays long,really long. I'ld like to work with you because you are a market leader in processing geospatial data. I'hv previously worked on an open source project for automating the event registration process of F.C.R.I.T,Mumbai University.I then received the letter of Recommendation for the same. *My passion for this project:* I started working on geospatial data a year ago as a part of my final year project which was "Parallel Computing in Data Mining Algorithms" which secured the third prize in an International Project Competition at Veltech University organized by CSI and IEEE. This field excites me a lot because of the room of development that can be made to it. *Paper Published:* http://ijates.com/images/short_pdf/1419962383_P589-596.pdf *Time-availability:* Yes I do consider this as an opportunity to do something significant and agree to devote my 100% to it.No time issues from my side. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parm11.java Type: application/octet-stream Size: 2725 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parm22.c Type: text/x-csrc Size: 8696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parm33.c Type: text/x-csrc Size: 49934 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: parm44.java Type: application/octet-stream Size: 14615 bytes Desc: not available URL: From amitabh.tiwari27 at gmail.com Wed Apr 1 09:18:44 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Wed, 1 Apr 2015 21:48:44 +0530 Subject: [GRASS-dev] RSI-image-data sets Message-ID: Data sets for the codes submitted before. Please provide feedback and currently I'am working on fixing bugs in (i.* modules). Explanation: Suppose the event is Crop yield production and the contributing factor that contributes towards the success of event is Rainfall. Then, geo1-crop yield of region A geo2-rainfall of region A geo3-rainfall of region B output image-My algorithm predicts it i.e. crop yield of region B. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geo1.jpg Type: image/jpeg Size: 3964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geo2.jpg Type: image/jpeg Size: 3975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geo3.jpg Type: image/jpeg Size: 3938 bytes Desc: not available URL: From trac at osgeo.org Wed Apr 1 23:28:42 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 02 Apr 2015 06:28:42 -0000 Subject: [GRASS-dev] [GRASS GIS] #2607: Python shell hint results in OSError error(None): None In-Reply-To: <040.3971a1a2a8e964a352aaac26d5a40d5c@osgeo.org> References: <040.3971a1a2a8e964a352aaac26d5a40d5c@osgeo.org> Message-ID: <049.b4ee73b70aca73dffc779f65a2515e94@osgeo.org> #2607: Python shell hint results in OSError error(None): None -------------------------+-------------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: Component: wxGUI | Version: 7.0.0 Keywords: | Platform: All Cpu: Unspecified | -------------------------+-------------------------------------------------- Comment(by zarch): Replying to [comment:2 annakrat]: > Replying to [comment:1 marisn]: > > Same happens with 7.1 SVN on GNU/Linux, still error message is a bit different: "OSError error(2): No such file or directory" > > It works fine for me using Ubuntu. Does it happen only in the Python shell in wxGUI? I have the same error also in ipython shell: {{{ In [2]: r.OSError error(2): No such file or directory OSError error(2): No such file or directory Display all 187 possibilities? (y or n) r.basin_fill r.buffer ... }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 2 06:52:40 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 02 Apr 2015 13:52:40 -0000 Subject: [GRASS-dev] [GRASS GIS] #2638: r.to.vect: ignore Null cells Message-ID: <042.2e71bf78a62161241f604ae91b267117@osgeo.org> #2638: r.to.vect: ignore Null cells -------------------------+-------------------------------------------------- Reporter: awickert | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Default | Version: svn-trunk Keywords: r.to.vect | Platform: Unspecified Cpu: x86-64 | -------------------------+-------------------------------------------------- When I have sparse raster files and want to turn them into vectors, it takes a long time because of the unnecessary conversion of all the NULL cells. It would be great (and possibly easy?) if there were a flag to tell GRASS to ignore all NULL cells. -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 2 07:19:59 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 02 Apr 2015 14:19:59 -0000 Subject: [GRASS-dev] [GRASS GIS] #2638: r.to.vect: ignore Null cells In-Reply-To: <042.2e71bf78a62161241f604ae91b267117@osgeo.org> References: <042.2e71bf78a62161241f604ae91b267117@osgeo.org> Message-ID: <051.983c0c2c188d48926972eadacb1d1e19@osgeo.org> #2638: r.to.vect: ignore Null cells --------------------------+------------------------------------------------- Reporter: awickert | Owner: grass-dev@? Type: enhancement | Status: closed Priority: normal | Milestone: 7.1.0 Component: Default | Version: svn-trunk Resolution: invalid | Keywords: r.to.vect Platform: Unspecified | Cpu: x86-64 --------------------------+------------------------------------------------- Changes (by awickert): * status: new => closed * resolution: => invalid Comment: Sorry -- I read the output incorrectly! This is already done. -- Ticket URL: GRASS GIS From doug_newcomb at fws.gov Thu Apr 2 08:15:32 2015 From: doug_newcomb at fws.gov (Newcomb, Doug) Date: Thu, 2 Apr 2015 11:15:32 -0400 Subject: [GRASS-dev] Standalone GRASS 7 windows installer 64 bit? Message-ID: Hi Folks I have a training class for Lidar coming up for which I would like to use GRASS 7. However the standalone installer for windows crashes ( GRASS 7 has stopped working message) whenever I try to import las data in the laszip format. ( LAS format works fine). This appears to have been fixed in the 64 bit build of OSGeo4W, see http://trac.osgeo.org/osgeo4w/ticket/429, but not in the 32 bit build ( hence the crash) Is there any timeline on a 64 bit build of the standalone installer for GRASS 7 for windows? Doug -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newcomb at fws.gov --------------------------------------------------------------------------------------------------------- The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -------------- next part -------------- An HTML attachment was scrubbed... URL: From landa.martin at gmail.com Thu Apr 2 08:29:04 2015 From: landa.martin at gmail.com (Martin Landa) Date: Thu, 2 Apr 2015 17:29:04 +0200 Subject: [GRASS-dev] Standalone GRASS 7 windows installer 64 bit? In-Reply-To: References: Message-ID: Hi, 2015-04-02 17:15 GMT+02:00 Newcomb, Doug : > Is there any timeline on a 64 bit build of the standalone installer for > GRASS 7 for windows? unfortunately no timeline, I hope to have finish 64bit builds soon... Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From doug_newcomb at fws.gov Thu Apr 2 08:32:33 2015 From: doug_newcomb at fws.gov (Newcomb, Doug) Date: Thu, 2 Apr 2015 11:32:33 -0400 Subject: [GRASS-dev] Standalone GRASS 7 windows installer 64 bit? In-Reply-To: References: Message-ID: Martin, Thank you for your efforts! I'll keep my training planning flexible. Doug On Thu, Apr 2, 2015 at 11:29 AM, Martin Landa wrote: > Hi, > > 2015-04-02 17:15 GMT+02:00 Newcomb, Doug : > > Is there any timeline on a 64 bit build of the standalone installer for > > GRASS 7 for windows? > > unfortunately no timeline, I hope to have finish 64bit builds soon... > Martin > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newcomb at fws.gov --------------------------------------------------------------------------------------------------------- The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Thu Apr 2 09:02:35 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 02 Apr 2015 16:02:35 -0000 Subject: [GRASS-dev] [GRASS GIS] #2639: grass command should read commands from stdin as an interpreter would do Message-ID: <044.dc10e276d607fb32e135ca062ca33237@osgeo.org> #2639: grass command should read commands from stdin as an interpreter would do --------------------------------------------------------------------------------------+ Reporter: wenzeslaus | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Startup | Version: unspecified Keywords: interface, CLI, script, batch job, GRASS_BATCH_JOB, init, standard input | Platform: All Cpu: Unspecified | --------------------------------------------------------------------------------------+ GRASS GIS works as something between set of command line tools (e.g. GDAL, or POSIX utilities) and an interpreter with unique commands or syntax (Python, R). However, GRASS GIS does not behave as the former because the tools are not available in standard command line (system environment). Unfortunately, `grass` (`grass7`) command does not behave as an interpreter neither because it does not allow scripts to be executed in the same way as with the standard interpreters. Standard interpreters allow to provide commands/script as standard input: {{{ $ python < a = 5 > print(a) > EOF 5 }}} {{{ $ R --vanilla --silent < a = 5 > print(a) [1] 5 > }}} {{{ $ bash < output.txt <: aspect elevation_shade lsat7_2002_70 basin_50K facility lsat7_2002_80 ... elev_state_500m lsat7_2002_61 zipcodes_dbl elevation lsat7_2002_62 ESC[HESC[2J }}} The question is also if there should be the screen cleaning/reset at all; neither Python nor R are using it: {{{ $ $ python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> exit() $ }}} {{{ $ $ R R version 3.0.2 (2013-09-25) -- "Frisbee Sailing" Copyright (C) 2013 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > q() Save workspace image? [y/n/c]: n $ }}} Regarding the welcome text (version, copyright, help, etc.) `python` and `sqlite3` distinguish between interactive invocation (`python`) and input from script or stdin (`python script.py`, `python < GRASS GIS From amitabh.tiwari27 at gmail.com Thu Apr 2 21:16:03 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Fri, 3 Apr 2015 09:46:03 +0530 Subject: [GRASS-dev] Feedback-regarding codes submitted. Message-ID: Hello everyone, Please provide your valuable feedback about the work done till date by me.I'am new to this forum and expecting guidance from you all. Regards, Amitabh -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.vanbreugel at gmail.com Fri Apr 3 02:22:51 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Fri, 3 Apr 2015 11:22:51 +0200 Subject: [GRASS-dev] Inconsistent number of columns in the table Message-ID: After importing a vector map in GRASS GIS, when I try to open the table manager, I get the message that there is a "Inconsistent number of columns in the table " I can open the same table without problems in sqlite managers such as navigat and sqlite manager. I suspect the text in one or more of the entries contains a character that is interpreted as delimiter by the table manager. What characters are interpreted as delimiters by the table manager (so I know what to look for)? Or is there another likely reason for this problem? Paulo Running GRASS 7dev on Linux. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratochanna at gmail.com Fri Apr 3 05:34:45 2015 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Fri, 3 Apr 2015 08:34:45 -0400 Subject: [GRASS-dev] Inconsistent number of columns in the table In-Reply-To: References: Message-ID: On Fri, Apr 3, 2015 at 5:22 AM, Paulo van Breugel wrote: > After importing a vector map in GRASS GIS, when I try to open the table > manager, I get the message that there is a "Inconsistent number of columns > in the table " > > I can open the same table without problems in sqlite managers such as > navigat and sqlite manager. > > I suspect the text in one or more of the entries contains a character that > is interpreted as delimiter by the table manager. What characters are > interpreted as delimiters by the table manager (so I know what to look > for)? Or is there another likely reason for this problem? > That's weird because the separator is composed of multiple characters (it is string '{_sep_}'), so very unlikely to be in the data. Could you share the data to test? Anna > > Paulo > > Running GRASS 7dev on Linux. > > > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Fri Apr 3 07:18:45 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Fri, 3 Apr 2015 10:18:45 -0400 Subject: [GRASS-dev] [GRASS-SVN] r64921 - in grass/branches/releasebranch_7_0/gui/wxpython: gui_core lmgr In-Reply-To: <20150325202602.1CB253901E5@trac.osgeo.org> References: <20150325202602.1CB253901E5@trac.osgeo.org> Message-ID: Hi, I'm sorry to criticize new features but I'm afraid it is necessary. On Wed, Mar 25, 2015 at 4:26 PM, wrote: > > Author: martinl > Date: 2015-03-25 13:26:02 -0700 (Wed, 25 Mar 2015) > New Revision: 64921 > > Modified: > grass/branches/releasebranch_7_0/gui/wxpython/gui_core/forms.py > grass/branches/releasebranch_7_0/gui/wxpython/lmgr/giface.py > Log: > wxGUI: gselect.Select() - show grouped maps from map display > LayerList - add len() > (merge r64855:6 from trunk) First, this is a feature, not a bug fix. Do we backport features to 70 branch? In we even backport features, is 11 days in between the original commit and backport enough? It is quite a few days but I suppose that a lot of people who were using trunk are now using release branch or even the stable release, so the number of testers is lower than it was before 7.0.0 release. > Modified: grass/branches/releasebranch_7_0/gui/wxpython/gui_core/forms.py > if maps_param and orig_elem == 'stds': > element_dict = {'raster': 'strds', 'vector': 'stvds', 'raster_3d': 'str3ds'} > elem = element_dict[type_param.get('default')] > - > - if self._giface and hasattr(self._giface, "_model"): > - extraItems = {_('Graphical Modeler') : self._giface.GetLayerList(p.get('prompt'))} > - else: > - extraItems = None > + > + extraItems = None > + if self._giface: > + if hasattr(self._giface, "_model"): > + extraItems = {_('Graphical Modeler') : self._giface.GetLayerList(p.get('prompt'))} > + else: > + layers = self._giface.GetLayerList() > + if len(layers) > 0: > + mapList = [] > + extraItems = {_('Map Display') : mapList} > + for layer in layers: > + if layer.type != p.get('prompt'): > + continue > + mapList.append(str(layer)) > selection = gselect.Select(parent = which_panel, id = wx.ID_ANY, > size = globalvar.DIALOG_GSELECT_SIZE, > type = elem, multiple = multiple, nmaps = len(p.get('key_desc', [])), Also, this code is not well designed and although I might agree with committing the code to trunk, I don't think that this should be backported when it is not a bugfix. There are two basic problems with the code. First, it does the same think using giface but in two completely different ways. giface is here to avoid these object specific conditions. This means that either the new code is wrong or that the giface is not perfect. If later is true, then giface should be fixed, not workarounded. Second, how do you envision that this will work for different cases, e.g. in g.gui.iclass? Will there be another condition with _("Classification Tool")? The form.py should not depend on particular tools/components in GUI nor it should contain the code which is specific to these tools and thus this code should be part of these tools. Use of hasattr should always raise a red flag. The way out in this case is probably better/extended giface and/or parameter for the form dialog which allows to add or customize source of additional items and its label. I suggest to revert r64921 and significantly redo r64855. Vaclav https://trac.osgeo.org/grass/changeset/64855 https://trac.osgeo.org/grass/changeset/64856 https://trac.osgeo.org/grass/changeset/64921 -------------- next part -------------- An HTML attachment was scrubbed... URL: From landa.martin at gmail.com Fri Apr 3 07:25:09 2015 From: landa.martin at gmail.com (Martin Landa) Date: Fri, 3 Apr 2015 16:25:09 +0200 Subject: [GRASS-dev] [GRASS-SVN] r64921 - in grass/branches/releasebranch_7_0/gui/wxpython: gui_core lmgr In-Reply-To: References: <20150325202602.1CB253901E5@trac.osgeo.org> Message-ID: 2015-04-03 16:18 GMT+02:00 Vaclav Petras : [...] > I suggest to revert r64921 I can live with that. > and significantly redo r64855. OK, please DO it if you have enough time. Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From trac at osgeo.org Fri Apr 3 07:39:31 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 03 Apr 2015 14:39:31 -0000 Subject: [GRASS-dev] [GRASS GIS] #2640: newline in attribute table record Message-ID: <042.3226719292e719978c447d527c9d7bcb@osgeo.org> #2640: newline in attribute table record -------------------------------------------------+-------------------------- Reporter: annakrat | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Database | Version: svn-releasebranch70 Keywords: v.db.select, dbmgr, attribute table | Platform: All Cpu: Unspecified | -------------------------------------------------+-------------------------- I attached a testing shapefile where some of the records have a newline. Then v.db.select gives: {{{ cat|LABEL|LABEL2 1|Newline at the end |xx 2|Newline In the middle|xx 3|No newline here|xx }}} This can't be parsed correctly and as a result Attribute manager fails with inconsistent number of attributes. It's not just problem of GUI, this will affect any parsing in a user script for example. One possibility would be to use different format, for example JSON. -- Ticket URL: GRASS GIS From kratochanna at gmail.com Fri Apr 3 07:42:21 2015 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Fri, 3 Apr 2015 10:42:21 -0400 Subject: [GRASS-dev] Inconsistent number of columns in the table In-Reply-To: References: Message-ID: On Fri, Apr 3, 2015 at 8:34 AM, Anna Petr??ov? wrote: > > > On Fri, Apr 3, 2015 at 5:22 AM, Paulo van Breugel > wrote: > >> After importing a vector map in GRASS GIS, when I try to open the table >> manager, I get the message that there is a "Inconsistent number of columns >> in the table " >> >> I can open the same table without problems in sqlite managers such as >> navigat and sqlite manager. >> >> I suspect the text in one or more of the entries contains a character >> that is interpreted as delimiter by the table manager. What characters are >> interpreted as delimiters by the table manager (so I know what to look >> for)? Or is there another likely reason for this problem? >> > > That's weird because the separator is composed of multiple characters (it > is string '{_sep_}'), so very unlikely to be in the data. Could you share > the data to test? > > New ticket: http://trac.osgeo.org/grass/ticket/2640 There is a newline in record #406, try to remove it first (it shouldn't be there anyway in this case), then it should work. > Anna > >> >> Paulo >> >> Running GRASS 7dev on Linux. >> >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Fri Apr 3 07:47:54 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Fri, 3 Apr 2015 10:47:54 -0400 Subject: [GRASS-dev] [GRASS-SVN] r64921 - in grass/branches/releasebranch_7_0/gui/wxpython: gui_core lmgr In-Reply-To: References: <20150325202602.1CB253901E5@trac.osgeo.org> Message-ID: On Fri, Apr 3, 2015 at 10:25 AM, Martin Landa wrote: > > and significantly redo r64855. > > OK, please DO it if you have enough time. > Well, I don't have enough time for this, so in order to have sustainable and maintainable code base I think we should consider reverting r64855 as well. More importantly, do we backport features from trunk to release branch 70? -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Fri Apr 3 07:50:50 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 03 Apr 2015 14:50:50 -0000 Subject: [GRASS-dev] [GRASS GIS] #2641: Copy cat value to a new layer does not work Message-ID: <044.b75fd60bacacff14e99a1bb3ee1e5b79@osgeo.org> #2641: Copy cat value to a new layer does not work -------------------------+-------------------------------------------------- Reporter: pvanbosgeo | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Default | Version: unspecified Keywords: | Platform: Unspecified Cpu: Unspecified | -------------------------+-------------------------------------------------- I have a vector map with layer=1 linked to attribute table and layer=2 providing the number of overlapping categories. Aim is to create a third layer with unique values for each feature/polygon. The third step below, uploading the cat values from layer 2 to layer 3 doesn't work. # Add layer 3 to the vector layer test # add attribute table v.category test op=add layer=3 type=centroid out=test2 v.db.addtable test2 layer=3 column="cat2 integer" # Upload cat from layer 2 to layer 3 v.to.db test2 layer=3 query_layer=2 op=cat columns=cat2 Error message: ... WARNING: Record (cat 75456) already exists (not inserted) WARNING: Record (cat 75457) already exists (not inserted) WARNING: Record (cat 75458) already exists (not inserted) WARNING: Record (cat 75459) already exists (not inserted) WARNING: Record (cat 75460) already exists (not inserted) 100% 75460 categories read from vector map (layer 3) 75460 records selected from table (layer 2) 75460 categories read from vector map exist in selection from table 0 records updated/inserted (layer 3) -- Ticket URL: GRASS GIS From p.vanbreugel at gmail.com Fri Apr 3 07:53:36 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Fri, 3 Apr 2015 16:53:36 +0200 Subject: [GRASS-dev] Inconsistent number of columns in the table In-Reply-To: References: Message-ID: On Fri, Apr 3, 2015 at 4:42 PM, Anna Petr??ov? wrote: > > > On Fri, Apr 3, 2015 at 8:34 AM, Anna Petr??ov? > wrote: > >> >> >> On Fri, Apr 3, 2015 at 5:22 AM, Paulo van Breugel > > wrote: >> >>> After importing a vector map in GRASS GIS, when I try to open the table >>> manager, I get the message that there is a "Inconsistent number of columns >>> in the table " >>> >>> I can open the same table without problems in sqlite managers such as >>> navigat and sqlite manager. >>> >>> I suspect the text in one or more of the entries contains a character >>> that is interpreted as delimiter by the table manager. What characters are >>> interpreted as delimiters by the table manager (so I know what to look >>> for)? Or is there another likely reason for this problem? >>> >> >> That's weird because the separator is composed of multiple characters (it >> is string '{_sep_}'), so very unlikely to be in the data. Could you share >> the data to test? >> >> > New ticket: > http://trac.osgeo.org/grass/ticket/2640 > > There is a newline in record #406, try to remove it first (it shouldn't be > there anyway in this case), then it should work. > Thanks Anna. Out of curiosity, and so I can find this kind of problems myself next time, how did you find the problematic line? > > >> Anna >> >>> >>> Paulo >>> >>> Running GRASS 7dev on Linux. >>> >>> >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratochanna at gmail.com Fri Apr 3 08:00:59 2015 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Fri, 3 Apr 2015 11:00:59 -0400 Subject: [GRASS-dev] Inconsistent number of columns in the table In-Reply-To: References: Message-ID: On Fri, Apr 3, 2015 at 10:53 AM, Paulo van Breugel wrote: > > > On Fri, Apr 3, 2015 at 4:42 PM, Anna Petr??ov? > wrote: > >> >> >> On Fri, Apr 3, 2015 at 8:34 AM, Anna Petr??ov? >> wrote: >> >>> >>> >>> On Fri, Apr 3, 2015 at 5:22 AM, Paulo van Breugel < >>> p.vanbreugel at gmail.com> wrote: >>> >>>> After importing a vector map in GRASS GIS, when I try to open the table >>>> manager, I get the message that there is a "Inconsistent number of columns >>>> in the table " >>>> >>>> I can open the same table without problems in sqlite managers such as >>>> navigat and sqlite manager. >>>> >>>> I suspect the text in one or more of the entries contains a character >>>> that is interpreted as delimiter by the table manager. What characters are >>>> interpreted as delimiters by the table manager (so I know what to look >>>> for)? Or is there another likely reason for this problem? >>>> >>> >>> That's weird because the separator is composed of multiple characters >>> (it is string '{_sep_}'), so very unlikely to be in the data. Could you >>> share the data to test? >>> >>> >> New ticket: >> http://trac.osgeo.org/grass/ticket/2640 >> >> There is a newline in record #406, try to remove it first (it shouldn't >> be there anyway in this case), then it should work. >> > > Thanks Anna. Out of curiosity, and so I can find this kind of problems > myself next time, how did you find the problematic line? > I put some print statements in gui/wxpython/dbmgr/base.py and the last printed record was the bad one. > >> >> >>> Anna >>> >>>> >>>> Paulo >>>> >>>> Running GRASS 7dev on Linux. >>>> >>>> >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev at lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Fri Apr 3 18:01:05 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 04 Apr 2015 01:01:05 -0000 Subject: [GRASS-dev] [GRASS GIS] #1173: v.surf.rst: bug in handling Output deviations vector point file In-Reply-To: <039.3698165b323ccf17391a703907dffca7@osgeo.org> References: <039.3698165b323ccf17391a703907dffca7@osgeo.org> Message-ID: <048.2960d7ce79aa10f207569776a239a883@osgeo.org> #1173: v.surf.rst: bug in handling Output deviations vector point file ---------------------------------+------------------------------------------ Reporter: mmetz | Owner: grass-dev@? Type: defect | Status: new Priority: trivial | Milestone: 7.1.0 Component: Vector | Version: svn-releasebranch64 Keywords: vector, rst library | Platform: All Cpu: All | ---------------------------------+------------------------------------------ Changes (by wenzeslaus): * priority: normal => trivial * milestone: 6.4.4 => 7.1.0 Comment: According to analysis in this ticket, the issue is small because the pointer is used just to test against NULL and not to actual access to the memory (which would be disaster in this case). It should be fixed anyway, obviously. One possible way to go is to start by putting the code from `IL_init_params_2d()` to where the function is used. The function anyway just sets the attributes of a structure, setting them directly can be actually much more readable. -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 4 02:26:55 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 04 Apr 2015 09:26:55 -0000 Subject: [GRASS-dev] [GRASS GIS] #2642: Profile surface map not working Message-ID: <042.d9d87db1a4a8d4efcedf619736110227@osgeo.org> #2642: Profile surface map not working -------------------------+-------------------------------------------------- Reporter: humu2015 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Default | Version: unspecified Keywords: | Platform: Unspecified Cpu: Unspecified | -------------------------+-------------------------------------------------- The 'profile surface map' tool under the 'Analyse map' tool in the display window is not working. It does not even show a menu. The output of the command console is in the attached txt file -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 4 05:02:26 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 04 Apr 2015 12:02:26 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults Message-ID: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- In some cases, d.vect segfaults. I can only reproduce a segfault when I am in a directory with a long name (and the location name needs to be long too, though I surmise that it is the same issue). Here is the backtrace {{{ gdb --args d.vect map=selection_demand icon=basic/circle Reading symbols from /localdata/local/grass-7.0.0svn/bin/d.vect...done. (gdb) run Starting program: /localdata/local/grass-7.0.0svn/bin/d.vect map=selection_demand icon=basic/circle [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6cd2bef in store_xy (x=750.5, y=-nan(0x8000000000000)) at draw_line.c:22 22 png.grid[yi * png.width + xi] = png.current_color; (gdb) bt #0 0x00007ffff6cd2bef in store_xy (x=750.5, y=-nan(0x8000000000000)) at draw_line.c:22 #1 0x00007ffff6cd2fe9 in draw_line (x1=, y1=, x2=, y2=) at draw_line.c:60 #2 png_draw_line (x1=, y1=, x2=, y2=) at draw_line.c:73 #3 0x00007ffff68c8908 in path_stroke (p=0x7ffff6ed76a0, line=0x7ffff6cd2c00 ) at path.c:106 #4 0x00007ffff7dfa42e in symbol (Symb=0x8359b0, x0=-1474999.7945148, y0=3456000.0026465799, fill_color=0x835920, line_color=0x835900, string_color=0x835900) at symbol.c:93 #5 0x0000000000406014 in draw_line (Map=0x7fffffffd1b0, type=87, Clist=0x630400, color=0x7fffffffdcb0, fcolor=0x7fffffffdca0, chcat=0, symbol_name=0x6289d0 "basic/circle", size=5, sqrt_flag=0, id_flag=0, cats_color_flag=0, default_width=0, width_scale=1, zcolors=0x0, cvarr_rgb=0x0, colors=0x0, cvarr_width=0x7fffffffafb0, nrec_width=0, cvarr_size=0x7fffffffaf90, nrec_size=0, cvarr_rot=0x7fffffffaf70, nrec_rot=0) at lines.c:350 #6 display_lines (Map=0x7fffffffd1b0, type=87, Clist=0x630400, color=0x7fffffffdcb0, fcolor=0x7fffffffdca0, chcat=0, symbol_name=0x6289d0 "basic/circle", size=5, sqrt_flag=0, id_flag=0, cats_color_flag=0, default_width=0, width_scale=1, zcolors=0x0, cvarr_rgb=0x0, colors=0x0, cvarr_width=0x7fffffffafb0, nrec_width=0, cvarr_size=0x7fffffffaf90, nrec_size=0, cvarr_rot=0x7fffffffaf70, nrec_rot=0) at lines.c:150 #7 0x0000000000408716 in display_shape (Map=0x7fffffffd1b0, type=87, Clist=0x630400, window=0x7fffffffdba0, bcolor=0x7fffffffdcb0, fcolor=0x7fffffffdca0, chcat=0, icon=0x6289d0 "basic/circle", size=5, size_column=0x0, sqrt_flag=0, rot_column=0x0, id_flag=0, cats_colors_flag=0, rgb_column=0x0, default_width=0, width_column=0x0, width_scale=1, z_style=0x0) at shape.c:207 #8 0x00000000004073ed in main (argc=0, argv=0x0) at main.c:408 }}} I attach a reproducer. You may want to change GRASS_VERSION in reproduce.sh and code in grass_common_setup.sh. -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 4 10:38:33 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 04 Apr 2015 17:38:33 -0000 Subject: [GRASS-dev] [GRASS GIS] #2642: Profile surface map not working In-Reply-To: <042.d9d87db1a4a8d4efcedf619736110227@osgeo.org> References: <042.d9d87db1a4a8d4efcedf619736110227@osgeo.org> Message-ID: <051.c6314b09c6c9f9b404dac6a8b6587e34@osgeo.org> #2642: Profile surface map not working --------------------------+------------------------------------------------- Reporter: humu2015 | Owner: grass-dev@? Type: defect | Status: closed Priority: normal | Milestone: 7.0.1 Component: Default | Version: unspecified Resolution: duplicate | Keywords: Platform: Unspecified | Cpu: Unspecified --------------------------+------------------------------------------------- Changes (by annakrat): * status: new => closed * resolution: => duplicate Comment: Duplicate of your ticket #2558. -- Ticket URL: GRASS GIS From landa.martin at gmail.com Sat Apr 4 12:08:30 2015 From: landa.martin at gmail.com (Martin Landa) Date: Sat, 4 Apr 2015 21:08:30 +0200 Subject: [GRASS-dev] [GRASS-SVN] r64921 - in grass/branches/releasebranch_7_0/gui/wxpython: gui_core lmgr In-Reply-To: References: <20150325202602.1CB253901E5@trac.osgeo.org> Message-ID: Hi, 2015-04-03 16:47 GMT+02:00 Vaclav Petras : > Well, I don't have enough time for this, so in order to have sustainable and > maintainable code base I think we should consider reverting r64855 as well. well, I am against it, it's very useful feature. Feel free to add at least comments or suggestions to the code. > More importantly, do we backport features from trunk to release branch 70? Small improvements are allowed I would say, we are not in soft freeze. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From trac at osgeo.org Sun Apr 5 08:48:51 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 05 Apr 2015 15:48:51 -0000 Subject: [GRASS-dev] [GRASS GIS] #2065: grass70 not detecting latest source build of libLAS (1.7.0) In-Reply-To: <042.80aaf7c0db19384d42c9f075d2bf1f1c@osgeo.org> References: <042.80aaf7c0db19384d42c9f075d2bf1f1c@osgeo.org> Message-ID: <051.58687a0bd702e87926fe964aec6f42dc@osgeo.org> #2065: grass70 not detecting latest source build of libLAS (1.7.0) ------------------------+--------------------------------------------------- Reporter: rashadkm | Owner: grass-dev@? Type: defect | Status: closed Priority: normal | Milestone: 7.1.0 Component: Compiling | Version: svn-trunk Resolution: fixed | Keywords: liblas Platform: Linux | Cpu: All ------------------------+--------------------------------------------------- Changes (by epifanio): * cc: epifanio (added) * milestone: 7.0.0 => 7.1.0 Comment: Exact same problem building grass 7.1-svn on debian sid (liblas 1.8) -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 16:46:49 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 05 Apr 2015 23:46:49 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector Message-ID: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector -------------------------+-------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit | Platform: MacOSX Cpu: Unspecified | -------------------------+-------------------------------------------------- On mac OSX 10.10.2: python 2.7.9 (64 bit) wxmac 3.0.2 (64 bit) wxpython 3.0.2 (64 bit) grass built fine with no errors, load a raster and start to digitize a new vector. After the first vector feature is digitized the prompt to insert the attribute value is shown correctly but after hit enter to submit the vector feature record, the entire GUI freeze. No more action can be done, a force quit of the entire wxpython gui is needed. -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 16:52:26 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 05 Apr 2015 23:52:26 -0000 Subject: [GRASS-dev] [GRASS GIS] #2645: mac OSX - wxpython 3 (64 bit) profile surface map fails to start Message-ID: <042.72b208e284fecbb5d86c7d7b6796a4c6@osgeo.org> #2645: mac OSX - wxpython 3 (64 bit) profile surface map fails to start -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- From the wxpytho gui -> Analyze map -> profile surface map the widget doesn't load, the following log is printed in the shell (full debug enabled) : {{{ D1/5: G_set_program_name(): g.gisenv D2/5: G_option_to_separator(): key = separator -> sep = '/' GRASS 7.1.svn (NAD83_UTM_18N):~ > GUI D3/5: BaseToolbar.OnTool(): id = 179 GUI D1/5: Map.__init__(): None D1/5: grass.script.core.start_command(): g.tempfile -d pid=90304 D1/5: G_set_program_name(): g.tempfile D2/5: G_file_name(): path = /Users/epi/grass7data/NAD83_UTM_18N/PERMANENT D2/5: G_file_name(): path = /Users/epi/grass7data/NAD83_UTM_18N/PERMANENT/.tmp/epimac.local/90304.0 D1/5: grass.script.core.start_command(): g.gisenv -n D1/5: G_set_program_name(): g.gisenv D2/5: G_option_to_separator(): key = separator -> sep = ' ' GUI D1/5: gcmd.RunCommand(): g.proj -p D1/5: grass.script.core.start_command(): g.proj -p GUI D1/5: gcmd.RunCommand(): get return code 0 (0.035397 sec) GUI D3/5: gcmd.RunCommand(): return stdout '-PROJ_INFO------------------------------------------------- name : Universal Transverse Mercator proj : utm datum : nad83 ellps : grs80 zone : 18 no_defs : defined -PROJ_UNITS------------------------------------------------ unit : meter units : meters meters : 1 ' Traceback (most recent call last): File "/usr/local/grass-7.1.svn/gui/wxpython/mapdisp/frame.py", line 1081, in OnProfile self.Profile(rasters=rasters) File "/usr/local/grass-7.1.svn/gui/wxpython/mapdisp/frame.py", line 1089, in Profile controller=self.profileController) File "/usr/local/grass-7.1.svn/gui/wxpython/wxplot/profile.py", line 52, in __init__ BasePlotFrame.__init__(self, parent=parent, size=size, **kwargs) File "/usr/local/grass-7.1.svn/gui/wxpython/wxplot/base.py", line 88, in __init__ self.client = plot.PlotCanvas(self) File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/wx-3.0-osx_cocoa/wx/lib/plot.py", line 598, in __init__ self.HandCursor = wx.Cursor(Hand.GetImage()) File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/wx-3.0-osx_cocoa/wx/_gdi.py", line 1502, in __init__ _gdi_.Cursor_swiginit(self,_gdi_.new_Cursor(*args, **kwargs)) TypeError: Required argument 'type' (pos 2) not found }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 16:55:49 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 05 Apr 2015 23:55:49 -0000 Subject: [GRASS-dev] [GRASS GIS] #2646: mac OSX - wxpython 3 (64 bit) create histogram of raster map fails to start Message-ID: <042.bec4de475a376ade69861fd4610afe83@osgeo.org> #2646: mac OSX - wxpython 3 (64 bit) create histogram of raster map fails to start -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- From the wxpytho gui -> Analyze map -> create histogram of raster map the widget doesn't load, the following log is printed in the shell (full debug enabled) : {{{ GRASS 7.1.svn (NAD83_UTM_18N):~ > GUI D3/5: BaseToolbar.OnTool(): id = 179 GUI D1/5: Map.__init__(): None D1/5: grass.script.core.start_command(): g.tempfile -d pid=90304 D1/5: G_set_program_name(): g.tempfile D2/5: G_file_name(): path = /Users/epi/grass7data/NAD83_UTM_18N/PERMANENT D2/5: G_file_name(): path = /Users/epi/grass7data/NAD83_UTM_18N/PERMANENT/.tmp/epimac.local/90304.0 D1/5: grass.script.core.start_command(): g.gisenv -n D1/5: G_set_program_name(): g.gisenv D2/5: G_option_to_separator(): key = separator -> sep = ' ' GUI D1/5: gcmd.RunCommand(): g.proj -p D1/5: grass.script.core.start_command(): g.proj -p GUI D1/5: gcmd.RunCommand(): get return code 0 (0.043165 sec) GUI D3/5: gcmd.RunCommand(): return stdout '-PROJ_INFO------------------------------------------------- name : Universal Transverse Mercator proj : utm datum : nad83 ellps : grs80 zone : 18 no_defs : defined -PROJ_UNITS------------------------------------------------ unit : meter units : meters meters : 1 ' Traceback (most recent call last): File "/usr/local/grass-7.1.svn/gui/wxpython/mapdisp/frame.py", line 1104, in OnHistogramPyPlot win = HistogramPlotFrame(parent = self, rasterList = raster) File "/usr/local/grass-7.1.svn/gui/wxpython/wxplot/histogram.py", line 39, in __init__ BasePlotFrame.__init__(self, parent, size = size, **kwargs) File "/usr/local/grass-7.1.svn/gui/wxpython/wxplot/base.py", line 88, in __init__ self.client = plot.PlotCanvas(self) File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/wx-3.0-osx_cocoa/wx/lib/plot.py", line 598, in __init__ self.HandCursor = wx.Cursor(Hand.GetImage()) File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/wx-3.0-osx_cocoa/wx/_gdi.py", line 1502, in __init__ _gdi_.Cursor_swiginit(self,_gdi_.new_Cursor(*args, **kwargs)) TypeError: Required argument 'type' (pos 2) not found }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 17:08:38 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 00:08:38 -0000 Subject: [GRASS-dev] [GRASS GIS] #2647: mac OSX - wxpython 3 (64 bit) - ps.map fails to generate map preiew Message-ID: <042.40efd001f4f6b950c79a3a258b526689@osgeo.org> #2647: mac OSX - wxpython 3 (64 bit) - ps.map fails to generate map preiew ----------------------+----------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: Ps.map | Version: svn-trunk Keywords: | Platform: MacOSX Cpu: x86-64 | ----------------------+----------------------------------------------------- Trying to generate a simple pdf (single raster map + legend) the gui wx map composer freeze with the following log in the shell: {{{ GUI D1/5: gcmd.CommandThread(): ps.map --overwrite input=/Users/epi/grass7data/NAD83_UTM_18N/PERMANENT/.tmp/epimac.local/90304.1 output=/Users/epi/grass7data/NAD83_UTM_18N/PERMANENT/.tmp/epimac.local/90304.2 GUI D1/5: gcmd.RunCommand(): g.region rows=947 cols=1014 D1/5: grass.script.core.start_command(): g.region rows=947 cols=1014 GUI D1/5: gcmd.RunCommand(): get return code 0 (0.048446 sec) Apr 5 20:04:39 epimac.local Python[90304] : CGContextRestoreGState: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update. Traceback (most recent call last): File "/usr/local/grass-7.1.svn/gui/wxpython/psmap/frame.py", line 352, in OnCmdDone im.save(self.imgName, format = 'PNG') File "build/bdist.macosx-10.10-intel/egg/PIL/Image.py", line 1653, in save raise ValueError("unknown transformation method") File "build/bdist.macosx-10.10-intel/egg/PIL/EpsImagePlugin.py", line 336, in load fp.write("grestore end\n") File "build/bdist.macosx-10.10-intel/egg/PIL/EpsImagePlugin.py", line 143, in Ghostscript length = fp.tell() File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__ errread, errwrite) File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 17:40:23 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 00:40:23 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector In-Reply-To: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> References: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> Message-ID: <051.8d1c6b58fbef8d0233c0fbf82c71aae4@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector ---------------------------------+------------------------------------------ Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit, wxPython 3 | Platform: MacOSX Cpu: Unspecified | ---------------------------------+------------------------------------------ Changes (by annakrat): * keywords: v.digit => v.digit, wxPython 3 -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 17:43:20 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 00:43:20 -0000 Subject: [GRASS-dev] [GRASS GIS] #2645: mac OSX - wxpython 3 (64 bit) profile surface map fails to start In-Reply-To: <042.72b208e284fecbb5d86c7d7b6796a4c6@osgeo.org> References: <042.72b208e284fecbb5d86c7d7b6796a4c6@osgeo.org> Message-ID: <051.2a2b772e8fbfe4d689801ef2b96c91a1@osgeo.org> #2645: mac OSX - wxpython 3 (64 bit) profile surface map fails to start ------------------------+--------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: closed Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Resolution: duplicate | Keywords: Platform: MacOSX | Cpu: OSX/Intel ------------------------+--------------------------------------------------- Changes (by annakrat): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2558. -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 17:45:29 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 00:45:29 -0000 Subject: [GRASS-dev] [GRASS GIS] #2646: mac OSX - wxpython 3 (64 bit) create histogram of raster map fails to start In-Reply-To: <042.bec4de475a376ade69861fd4610afe83@osgeo.org> References: <042.bec4de475a376ade69861fd4610afe83@osgeo.org> Message-ID: <051.aa15608a8e5595a0991466765b50efb9@osgeo.org> #2646: mac OSX - wxpython 3 (64 bit) create histogram of raster map fails to start ------------------------+--------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: closed Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Resolution: duplicate | Keywords: Platform: MacOSX | Cpu: OSX/Intel ------------------------+--------------------------------------------------- Changes (by annakrat): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2558. -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 17:49:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 00:49:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2647: mac OSX - wxpython 3 (64 bit) - ps.map fails to generate map preiew In-Reply-To: <042.40efd001f4f6b950c79a3a258b526689@osgeo.org> References: <042.40efd001f4f6b950c79a3a258b526689@osgeo.org> Message-ID: <051.896578bf1744eb4cae2d6b82fdac3d22@osgeo.org> #2647: mac OSX - wxpython 3 (64 bit) - ps.map fails to generate map preiew -----------------------------------+---------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: cartographic composer | Platform: MacOSX Cpu: x86-64 | -----------------------------------+---------------------------------------- Changes (by annakrat): * keywords: => cartographic composer * component: Ps.map => wxGUI Comment: Do you have Ghostscript installed and on the path? -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 18:06:56 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 01:06:56 -0000 Subject: [GRASS-dev] [GRASS GIS] #2645: mac OSX - wxpython 3 (64 bit) profile surface map fails to start In-Reply-To: <042.72b208e284fecbb5d86c7d7b6796a4c6@osgeo.org> References: <042.72b208e284fecbb5d86c7d7b6796a4c6@osgeo.org> Message-ID: <051.4380583ac4b27b57b5d6fce2a7d5333f@osgeo.org> #2645: mac OSX - wxpython 3 (64 bit) profile surface map fails to start ------------------------+--------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: closed Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Resolution: duplicate | Keywords: Platform: MacOSX | Cpu: OSX/Intel ------------------------+--------------------------------------------------- Comment(by epifanio): Thank you so much to point me the the other tiket, I applied the patch : http://trac.wxwidgets.org/attachment/ticket/16767/wxPython-3.0.2.0-plot.patch And now both profile and histogram works fine. -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 5 18:12:45 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 01:12:45 -0000 Subject: [GRASS-dev] [GRASS GIS] #2647: mac OSX - wxpython 3 (64 bit) - ps.map fails to generate map preiew In-Reply-To: <042.40efd001f4f6b950c79a3a258b526689@osgeo.org> References: <042.40efd001f4f6b950c79a3a258b526689@osgeo.org> Message-ID: <051.396d7a606b4172aaad19f9fe3ab5bdaf@osgeo.org> #2647: mac OSX - wxpython 3 (64 bit) - ps.map fails to generate map preiew -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: closed Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Resolution: fixed | Keywords: cartographic composer Platform: MacOSX | Cpu: x86-64 -----------------------+---------------------------------------------------- Changes (by epifanio): * status: new => closed * resolution: => fixed Comment: Ghostscript was installed by homebrew, but for some reason not linked in the path. I forced the link and now both preview and ps output works fine -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 6 01:16:40 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 08:16:40 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults In-Reply-To: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> References: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> Message-ID: <051.d770282f92d47e3ad36f9ae6a17c9d0e@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by neteler): I have tried to reproduce it with your scripts but no issue here (Fedora 21, 64bit). In your report there are "", can you please recompile after "make distclean" without compiler optimization in order to obtain a better debugger report? -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 6 02:31:10 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 09:31:10 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults In-Reply-To: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> References: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> Message-ID: <051.74b318a1bc155d743b80376a9ed8e303@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by pertusus): Replying to [comment:1 neteler]: > I have tried to reproduce it with your scripts but no issue here (Fedora 21, 64bit). My platform is x86_64 CentOS release 6.6. Beware that to reproduce, you have to be in a long enough path. For example in {{{ /home/dumas/tmp/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/grass_bug_d_vect_segfault }}} > In your report there are "", can you please recompile after "make distclean" without compiler optimization in order to obtain a better debugger report? Here it is (recompiled with -O0): {{{ (gdb) bt #0 0x00007ffff6c9b3eb in store_xy (x=750.5, y=-nan(0x8000000000000)) at draw_line.c:22 #1 0x00007ffff6c9b61e in draw_line (x1=750.91808904861637, y1=35.342845063313966, x2=750.91808904861637, y2=35.342845063313966) at draw_line.c:60 #2 0x00007ffff6c9b6c9 in png_draw_line (x1=750.91808904861637, y1=35.342845063313966, x2=750.91808904861637, y2=35.342845063313966) at draw_line.c:73 #3 0x00007ffff689022d in path_stroke (p=0x7ffff6ea1260, line=0x7ffff6c9b647 ) at path.c:106 #4 0x00007ffff6c9b306 in PNG_Stroke () at draw.c:43 #5 0x00007ffff688e81f in COM_Stroke () at draw.c:38 #6 0x00007ffff7df72e6 in D_stroke () at draw2.c:326 #7 0x00007ffff7df9355 in symbol (Symb=0x8369b0, x0=-1474999.7945148, y0=3456000.0026465799, fill_color=0x836920, line_color=0x836900, string_color=0x836900) at symbol.c:93 #8 0x00007ffff7df94ff in D_symbol (Symb=0x8369b0, x0=-1474999.7945148, y0=3456000.0026465799, line_color=0x836900, fill_color=0x836920) at symbol.c:157 #9 0x00000000004066cf in draw_line (type=87, ltype=1, line=1, Points=0x836960, Cats=0x836990, color=0x7fffffffdb50, fcolor=0x7fffffffdb40, chcat=0, symbol_name=0x6299d0 "basic/circle", size=5, sqrt_flag=0, id_flag=0, cats_color_flag=0, default_width=0, width_scale=1, zcolors=0x0, cvarr_rgb=0x0, colors=0x0, cvarr_width=0x7fffffffd020, nrec_width=0, cvarr_size=0x7fffffffd000, nrec_size=0, cvarr_rot=0x7fffffffcfe0, nrec_rot=0, Clist=0x631400, Symb=0x8369b0, line_color=0x836900, fill_color=0x836920, primary_color=0x836940, n_points=0x7fffffffcca0, n_lines=0x7fffffffcc9c, n_centroids=0x7fffffffcc98, n_boundaries=0x7fffffffcc94, n_faces=0x7fffffffcc90) at lines.c:350 #10 0x0000000000405f1c in display_lines (Map=0x7fffffffd210, type=87, Clist=0x631400, color=0x7fffffffdb50, fcolor=0x7fffffffdb40, chcat=0, symbol_name=0x6299d0 "basic/circle", size=5, sqrt_flag=0, id_flag=0, cats_color_flag=0, default_width=0, width_scale=1, zcolors=0x0, cvarr_rgb=0x0, colors=0x0, cvarr_width=0x7fffffffd020, nrec_width=0, cvarr_size=0x7fffffffd000, nrec_size=0, cvarr_rot=0x7fffffffcfe0, nrec_rot=0) at lines.c:150 #11 0x00000000004091b5 in display_shape (Map=0x7fffffffd210, type=87, Clist=0x631400, window=0x7fffffffd190, bcolor=0x7fffffffdb50, fcolor=0x7fffffffdb40, chcat=0, icon=0x6299d0 "basic/circle", size=5, size_column=0x0, sqrt_flag=0, rot_column=0x0, id_flag=0, cats_colors_flag=0, rgb_column=0x0, default_width=0, width_column=0x0, width_scale=1, z_style=0x0) at shape.c:207 #12 0x0000000000407d90 in main (argc=3, argv=0x7fffffffddd8) at main.c:408 }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 6 04:36:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 11:36:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults In-Reply-To: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> References: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> Message-ID: <051.a12def1b5b43a2f2206613f963439802@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by pertusus): I poked around a bit in gdb, and my first impression is that the error is already in draw_line, it is never checked if x1 could be equal to x2, which means dx = 0, so at line 59, in {{{ y = y1 + (x - x1) * dy / dx; }}} y is set to nan and the segfault is a consequence of that. I have no idea whether x1 and X2 are supposed never to be equal or not. There are other points processed before the one that is problematic. It really puzzles me that I can only reproduce this when paths are long. There does not seems to be any relationship with that issue. My feeling is that the length of paths is unrelated to that issue, but for a mysterious reason, rounding of x1 and x2 depends on the path length and they are exactly equal only when the path is long but by complete chance. -- Ticket URL: GRASS GIS From neteler at osgeo.org Mon Apr 6 09:17:47 2015 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 6 Apr 2015 18:17:47 +0200 Subject: [GRASS-dev] Planning GRASS GIS 6.4.5 release In-Reply-To: References: Message-ID: On Tue, Mar 24, 2015 at 10:25 PM, Markus Neteler wrote: > Current state is at > http://trac.osgeo.org/grass/wiki/Grass6Planning I'll package RC1 tonight. Markus From trac at osgeo.org Mon Apr 6 09:41:33 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 16:41:33 -0000 Subject: [GRASS-dev] [GRASS GIS] #2160: wxPython 3: assertion 'width >= -1' failed In-Reply-To: <042.15c0b0710d0b8c1acfc9237093ef24ce@osgeo.org> References: <042.15c0b0710d0b8c1acfc9237093ef24ce@osgeo.org> Message-ID: <051.8c8155cdf093baf4bcef2887b12d2548@osgeo.org> #2160: wxPython 3: assertion 'width >= -1' failed -----------------------+---------------------------------------------------- Reporter: msieczka | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords: wxPython3 | Platform: All Cpu: All | -----------------------+---------------------------------------------------- Comment(by neteler): Attached a set of patches extracted from http://ftp.de.debian.org/debian/pool/main/g/grass/grass_6.4.4-1.debian.tar.xz then applied to current relbranch6 and regenerated + attached. Author: {{{ Description: Fix to work with wxPython 3.0 Author: Olly Betts Last-Update: 2014-08-16 }}} Please review. Ideally this should go into RC1. -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 6 11:46:57 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 18:46:57 -0000 Subject: [GRASS-dev] [GRASS GIS] #2160: wxPython 3: assertion 'width >= -1' failed In-Reply-To: <042.15c0b0710d0b8c1acfc9237093ef24ce@osgeo.org> References: <042.15c0b0710d0b8c1acfc9237093ef24ce@osgeo.org> Message-ID: <051.f1732bc76dd01b3767d455accaaa38af@osgeo.org> #2160: wxPython 3: assertion 'width >= -1' failed -----------------------+---------------------------------------------------- Reporter: msieczka | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 6.4.4 Component: wxGUI | Version: svn-releasebranch64 Keywords: wxPython3 | Platform: All Cpu: All | -----------------------+---------------------------------------------------- Comment(by neteler): Replying to [comment:3 neteler]: > http://ftp.de.debian.org/debian/pool/main/g/grass/grass_6.4.4-1.debian.tar.xz Extracted patch wxpy3.0-compat_patch_Debian.diff committed in r64997. -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 6 12:11:32 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 06 Apr 2015 19:11:32 -0000 Subject: [GRASS-dev] [GRASS GIS] #312: wxNVIZ prints debug to terminal In-Reply-To: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> References: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> Message-ID: <051.ac38ff2bcd3279a6bde2f996d59d1699@osgeo.org> #312: wxNVIZ prints debug to terminal -----------------------+---------------------------------------------------- Reporter: msieczka | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 6.4.3 Component: wxGUI | Version: svn-releasebranch64 Keywords: digitizer | Platform: All Cpu: All | -----------------------+---------------------------------------------------- Comment(by neteler): Still an issue. Does anyone know how to intercept GRASS_INFO_MESSAGE() etc to avoid that it gets printed to the terminal? -- Ticket URL: GRASS GIS From neteler at osgeo.org Mon Apr 6 15:10:18 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 7 Apr 2015 00:10:18 +0200 Subject: [GRASS-dev] GRASS GIS 6.4.5RC1 released Message-ID: After months of development a first release candidate of GRASS GIS 6.4.5 is now available. Source code download: http://grass.osgeo.org/grass64/source/ http://grass.osgeo.org/grass64/source/grass-6.4.5RC1.tar.gz Binaries download: http://grass.osgeo.org/download/software/#g64x To get the GRASS GIS 6.4.5RC1 source code directly from SVN: svn checkout http://svn.osgeo.org/grass/grass/tags/release_20150406_grass_6_4_5RC1 Key improvements: Key improvements of the GRASS GIS 6.4.5RC1 release include stability fixes (esp. vector library), some fixes for wxPython3 support, some module fixes, and more message translations. See also our detailed announcement: http://trac.osgeo.org/grass/wiki/Release/6.4.5RC1-News First time users should explore the first steps tutorial after installation: http://grasswiki.osgeo.org/wiki/Quick_wxGUI_tutorial Release candidate management at http://trac.osgeo.org/grass/wiki/Grass6Planning Please join us in testing this release candidate for the final release. Consider to donate pizza or beer for the next GRASS GIS Community Sprint (FOSS4G Europe 2015 in Como): http://grass.osgeo.org/donations/ Thanks to all contributors! GRASS Development Team From amitabh.tiwari27 at gmail.com Mon Apr 6 20:20:01 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Tue, 7 Apr 2015 08:50:01 +0530 Subject: [GRASS-dev] Video for my proposal Message-ID: Hi, Sorry I just mentioned about it in my proposal and did not attach it anywhere.Here is the video depicting the working of those codes.By tomorrow I will send the entire documentation including the requirements,Design,Architecture,Workflow diagrams,Flowcharts,Data flow and control flow diagrams for the implemented phase-1 of my proposal. Youtube link for the video : http://youtu.be/KbnQKMQy4N8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Mon Apr 6 21:30:37 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 07 Apr 2015 04:30:37 -0000 Subject: [GRASS-dev] [GRASS GIS] #2606: Bugs in r.sun In-Reply-To: <042.0c578eee7068ec8f15b5021f378c131f@osgeo.org> References: <042.0c578eee7068ec8f15b5021f378c131f@osgeo.org> Message-ID: <051.8a9bc77c45fd0ac64c7cf45e2056d467@osgeo.org> #2606: Bugs in r.sun ----------------------+----------------------------------------------------- Reporter: ojni0001 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: unspecified Keywords: r.sun | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by ojni0001): Creating Python script is not possible for me at the moment. I have created a shell script running in Windows7 OS. So, I guess it also runs on Linux machine. The script does not assume that data is present. It will create a raster data with 1 cell and runs the test. I cannot find a way to attach the code. Please see the script below: {{{ #!sh function fcomp() { awk -v n1=$1 -v n2=$2 'BEGIN{ if (n1 test_2606.txt g.mapset PERMANENT g.proj -c epsg=2449 g.region s=-83700 n=-83600 w=-23200 e=-23100 res=100 r.mapcalc --overwrite "const_elev = 15.0" days=( 17 47 75 105 135 162 198 228 258 288 318 344) month=( jan feb mar apr may jun jul aug sep oct nov dec) aspect=( 0.0 15.0 30.0 45.0 60.0 75.0 90.0 105.0 120.0 135.0 150.0 165.0 180.0 195.0 210.0 225.0 240.0 255.0 270.0 285.0 300.0 315.0 330.0 345.0 360.0) slope=( 0.0 10.0 20.0 30.0 40.0 50.0 60.0 70.0 80.0 90.0) for k in {0..11} do for i in {0..24} do for j in {0..9} do CMD="r.sun --overwrite --quiet elevation=const_elev aspect_value=${aspect[$i]} slope_value=${slope[$j]} linke_value=1.0 glob_rad=at1-g_${month[$k]}_${slope[$j]}_${aspect[$i]} day=${days[$k]} step=0.5" $CMD done done done fail1=0 fail2=0 fail3=0 fail4=0 count1=0 count2=0 count3=0 for k in {0..11} do #for i in {0..24} #lets check at aspect 0 and 180 degrees, the radiation value should be equal if 270 is south for i in 0 12 do ((i2=i+12)) for j in {0..9} do x1=`r.info -r at1-g_${month[$k]}_${slope[$j]}_${aspect[$i]} | grep "max" | cut -d = -f 2 ` x2=`r.info -r at1-g_${month[$k]}_${slope[$j]}_${aspect[$i2]} | grep "max" | cut -d = -f 2 ` diff_val=`awk "BEGIN {print $x1-$x2; exit}"` echo " month: ${month[$k]} aspect: ${aspect[$i]}; ${aspect[$i2]} slope=${slope[$j]}" >> test_2606.txt echo " x1=$x1 x2=$x2 difference: $diff_val" >> test_2606.txt ((count1=count1+1)) if [ $diff_val = 0 ];then echo " test passed" >> test_2606.txt else echo " test failed; bug remaining, east/west is not 0/180, south is not 270 degrees" >> test_2606.txt ((fail1=fail1+1)) fi done done wait done wait for k in {0..11} do #for i in {0..24} #lets check at aspect 90 and 270 degrees to check whether 90/270 is east/west or west/east for i in 6 do ((i2=i+12)) for j in {0..9} do x1=`r.info -r at1-g_${month[$k]}_${slope[$j]}_${aspect[$i]} | grep "max" | cut -d = -f 2 ` x2=`r.info -r at1-g_${month[$k]}_${slope[$j]}_${aspect[$i2]} | grep "max" | cut -d = -f 2 ` diff_val=`awk "BEGIN {print $x1-$x2; exit}"` ((count2=count2+1)) echo " month: ${month[$k]} aspect: ${aspect[$i]}; ${aspect[$i2]} slope=${slope[$j]}" >> test_2606.txt echo " x1=$x1 x2=$x2 difference: $diff_val" >> test_2606.txt if [ $diff_val = 0 ];then echo " values are equal at 90/270 bug remaining, east/west is 90/270 degrees" >> test_2606.txt ((fail2=fail2+1)) fi done done wait done wait for k in {0..11} do for i in {0..24} #for i in 6 do #for j in {0..9} for j in 7 do ((j2=j+1)) ((j3=j+2)) x1=`r.info -r at1-g_${month[$k]}_${slope[$j]}_${aspect[$i]} | grep "max" | cut -d = -f 2 ` x2=`r.info -r at1-g_${month[$k]}_${slope[$j2]}_${aspect[$i]} | grep "max" | cut -d = -f 2 ` x3=`r.info -r at1-g_${month[$k]}_${slope[$j3]}_${aspect[$i]} | grep "max" | cut -d = -f 2 ` diff_val1=`awk "BEGIN {print $x1-$x2; exit}"` diff_val2=`awk "BEGIN {print $x2-$x3; exit}"` ((count3=count3+1)) echo " month: ${month[$k]} aspect: ${aspect[$i]} slope=${slope[$j]} ${slope[$j2]} ${slope[$j3]}" >> test_2606.txt echo " x1=$x1 x2=$x2 x3=$x3 differences: $diff_val1 $diff_val2" >> test_2606.txt #if [ $diff_val1 > 0 ];then if fcomp 0 $diff_val1; then echo " $diff_val1 > 0; OK" >> test_2606.txt else echo " $diff_val1 < 0;bug remaining, ${slope[$j]} has less radiance than ${slope[$j2]}" >> test_2606.txt ((fail3=fail3+1)) fi #if [ $diff_val2 > 0 ];then if fcomp 0 $diff_val2; then echo " $diff_val2 > 0; OK" >> test_2606.txt else echo " $diff_val2 < 0;bug remaining, ${slope[$j2]} has less radiance than ${slope[$j3]}" >> test_2606.txt ((fail4=fail4+1)) fi done done wait done wait echo "e-w test fail:$fail1 of $count1; south test fail:$fail2 of $count2" >> test_2606.txt echo "e-w test fail:$fail1 of $count1; south test fail:$fail2 of $count2" echo "values for slope 70 and 80 fail:$fail3 of $count3; values for slope 80 and 90 fail:$fail4 of $count3" >> test_2606.txt echo "values for slope 70 and 80 fail:$fail3 of $count3; values for slope 80 and 90 fail:$fail4 of $count3" }}} -- Ticket URL: GRASS GIS From lucadeluge at gmail.com Mon Apr 6 22:18:41 2015 From: lucadeluge at gmail.com (Luca Delucchi) Date: Tue, 7 Apr 2015 07:18:41 +0200 Subject: [GRASS-dev] Next GRASS community sprint In-Reply-To: References: Message-ID: Hi devs, please consider to add you name to the list [0]. In the next days I'll start to contact owners to find a place where to stay... Thanks [0] http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Como_2015#In_person On 14 March 2015 at 22:58, Markus Neteler wrote: > Hi > > I'll will be there. And looking forward to it :) > > Markus -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org From ychemin at gmail.com Mon Apr 6 23:15:03 2015 From: ychemin at gmail.com (Yann Chemin) Date: Tue, 7 Apr 2015 11:45:03 +0530 Subject: [GRASS-dev] Next GRASS community sprint In-Reply-To: References: Message-ID: <02C01179-3EAB-4E2B-9BE6-BFF4D654015B@gmail.com> Wow ! Como ! Would be so fun ? > On Apr 7, 2015, at 10:48 AM, Luca Delucchi wrote: > > Hi devs, > > please consider to add you name to the list [0]. > > In the next days I'll start to contact owners to find a place where to stay... > > Thanks > > [0] http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Como_2015#In_person > > On 14 March 2015 at 22:58, Markus Neteler wrote: >> Hi >> >> I'll will be there. And looking forward to it :) >> >> Markus > > > > -- > ciao > Luca > > http://gis.cri.fmach.it/delucchi/ > www.lucadelu.org > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev From massimiliano.cannata at supsi.ch Tue Apr 7 00:19:50 2015 From: massimiliano.cannata at supsi.ch (Massimiliano Cannata) Date: Tue, 07 Apr 2015 07:19:50 +0000 Subject: [GRASS-dev] Next GRASS community sprint In-Reply-To: <02C01179-3EAB-4E2B-9BE6-BFF4D654015B@gmail.com> References: <02C01179-3EAB-4E2B-9BE6-BFF4D654015B@gmail.com> Message-ID: Hi there, you could also ask OSGeo for supporting the sprint. If you intend to do it, please prepare a request before of the next meeting (http://wiki.osgeo.org/wiki/Board_Meeting_2015-04-09) so that can be added to the agenda, discussed and voted. Maxi Il giorno mar 7 apr 2015 alle ore 08:15 Yann Chemin ha scritto: > Wow ! Como ! Would be so fun ? > > > On Apr 7, 2015, at 10:48 AM, Luca Delucchi wrote: > > > > Hi devs, > > > > please consider to add you name to the list [0]. > > > > In the next days I'll start to contact owners to find a place where to > stay... > > > > Thanks > > > > [0] http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_ > Como_2015#In_person > > > > On 14 March 2015 at 22:58, Markus Neteler wrote: > >> Hi > >> > >> I'll will be there. And looking forward to it :) > >> > >> Markus > > > > > > > > -- > > ciao > > Luca > > > > http://gis.cri.fmach.it/delucchi/ > > www.lucadelu.org > > _______________________________________________ > > grass-dev mailing list > > grass-dev at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-dev > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Tue Apr 7 01:08:01 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 7 Apr 2015 10:08:01 +0200 Subject: [GRASS-dev] Next GRASS community sprint In-Reply-To: References: <02C01179-3EAB-4E2B-9BE6-BFF4D654015B@gmail.com> Message-ID: On Tue, Apr 7, 2015 at 9:19 AM, Massimiliano Cannata wrote: > Hi there, > you could also ask OSGeo for supporting the sprint. > If you intend to do it, please prepare a request before of the next meeting > (http://wiki.osgeo.org/wiki/Board_Meeting_2015-04-09) so that can be added > to the agenda, discussed and voted. Additionally, we coul?d ask FOSSGIS e.V. to support the event as done in the past: http://www.fossgis.de/wiki/Kategorie:F%C3%B6rderantr%C3%A4ge --> GRASS GIS Community Sprint 2011, 2012, 2013 Markus From landa.martin at gmail.com Tue Apr 7 02:10:58 2015 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 7 Apr 2015 11:10:58 +0200 Subject: [GRASS-dev] pygrass - stdout2dict Message-ID: Hi, pygrass manual uses stdout2dict() [1] which doesn't seems to be available. Martin [1] http://grass.osgeo.org/grass70/manuals/libpython/pygrass_modules.html -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From neteler at osgeo.org Tue Apr 7 02:24:12 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 7 Apr 2015 11:24:12 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: On Tue, Apr 7, 2015 at 11:10 AM, Martin Landa wrote: > Hi, > > pygrass manual uses stdout2dict() [1] which doesn't seems to be > available. Martin > > [1] http://grass.osgeo.org/grass70/manuals/libpython/pygrass_modules.html While I don't know the solution, there were to related comments: http://lists.osgeo.org/pipermail/grass-user/2014-October/071144.html http://lists.osgeo.org/pipermail/grass-user/2014-October/071150.html Markus From peter.zamb at gmail.com Tue Apr 7 03:58:05 2015 From: peter.zamb at gmail.com (Pietro) Date: Tue, 7 Apr 2015 12:58:05 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: Hi Martin, On Tue, Apr 7, 2015 at 11:10 AM, Martin Landa wrote: > pygrass manual uses stdout2dict() [1] which doesn't seems to be > available. > > [1] http://grass.osgeo.org/grass70/manuals/libpython/pygrass_modules.html You are right the function has not been defined... probably I can simply update the docstring adding the function, something like: {{{ def stdout2dict(stdout): return dict([kv.split('=') for kv in stdout.strip().split('\n')]) }}} or with lambda {{{ stdout2dict = lambda x: dict([i.split('=') for i in x.strip().split('\n')]) }}} Best regards Pietro From landa.martin at gmail.com Tue Apr 7 04:05:52 2015 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 7 Apr 2015 13:05:52 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: 2015-04-07 12:58 GMT+02:00 Pietro : > You are right the function has not been defined... probably I can > simply update the docstring adding the function, something like: > > {{{ > def stdout2dict(stdout): > return dict([kv.split('=') for kv in stdout.strip().split('\n')]) > }}} > > or with lambda > > {{{ > stdout2dict = lambda x: dict([i.split('=') for i in x.strip().split('\n')]) > }}} hm, is there any way how to parse command output using pygrass without need to define your own function? Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From peter.zamb at gmail.com Tue Apr 7 04:28:56 2015 From: peter.zamb at gmail.com (Pietro) Date: Tue, 7 Apr 2015 13:28:56 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: On Tue, Apr 7, 2015 at 1:05 PM, Martin Landa wrote: > hm, is there any way how to parse command output using pygrass without > need to define your own function? Why not use: parse_key_val(s, sep='=', dflt=None, val_type=None, vsep=None) define in grass.script.utils? From landa.martin at gmail.com Tue Apr 7 04:54:25 2015 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 7 Apr 2015 13:54:25 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: 2015-04-07 13:28 GMT+02:00 Pietro : > On Tue, Apr 7, 2015 at 1:05 PM, Martin Landa wrote: >> hm, is there any way how to parse command output using pygrass without >> need to define your own function? > > Why not use: parse_key_val(s, sep='=', dflt=None, val_type=None, vsep=None) > > define in grass.script.utils? you are right, are you planning to update pygrass manual? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From peter.zamb at gmail.com Tue Apr 7 05:09:25 2015 From: peter.zamb at gmail.com (Pietro) Date: Tue, 7 Apr 2015 14:09:25 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: On Tue, Apr 7, 2015 at 1:54 PM, Martin Landa wrote: > you are right, are you planning to update pygrass manual? Martin done in r65015 Pietro From landa.martin at gmail.com Tue Apr 7 05:11:58 2015 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 7 Apr 2015 14:11:58 +0200 Subject: [GRASS-dev] pygrass - stdout2dict In-Reply-To: References: Message-ID: 2015-04-07 14:09 GMT+02:00 Pietro : > done in r65015 Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From neteler at osgeo.org Tue Apr 7 05:36:41 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 7 Apr 2015 14:36:41 +0200 Subject: [GRASS-dev] GRASS GIS 7.0.1 planning: potential backports Message-ID: Hi, I have been trying to track potential backports: * v.in.ogr: backport island recognition message (sync geom.c, main.c and v.in.ogr.html) * v.select: code optimization, no bug fix * r64993 - grass/trunk/gui/wxpython/vnet - Author: turek Date: 2015-04-06 * r64979 - grass/trunk/gui/wxpython/vnet - Author: turek Date: 2015-04-02 * r64898 - grass/trunk/scripts/r.unpack - Author: lucadelu Date: 2015-03-24 * r64895 - grass/trunk/raster/r.li: . r.li.daemon - Author: wenzeslaus Date: 2015-03-23 * r64854 - grass/trunk/gui/wxpython/lmgr - Author: wenzeslaus Date: 2015-03-14 * r64783 - grass/trunk/vector/v.vol.rst - Author: annakrat Date: 2015-03-02 * r64630 - grass/trunk/vector/v.net - Author: neteler Date: 2015-02-14 * r64470 - grass/trunk/lib/python/temporal - Author: huhabla Date: 2015-02-05 * r64226 - grass/trunk: gui/xml lib/gis - Author: glynn Date: 2015-01-16 * r63543 - grass/trunk/lib/btree2 - Author: mmetz Date: 2014-12-14 * r63378 - grass/trunk/raster/r.in.gdal - Author: mmetz Date: 2014-12-05 * r63374 - grass/trunk/lib/init - Author: martinl Date: 2014-12-05 * r63369 - grass/trunk/lib/python/docs/src - Author: wenzeslaus Date: 2014-12-04 * r63361 - grass/trunk/lib/display - Author: glynn Date: 2014-12-03 * r63308 - grass/trunk/lib/gis - Author: mmetz Date: 2014-11-30 * r63238 - grass/trunk: db/drivers/sqlite scripts/v.db.update - Author: neteler Date: 2014-11-28 * r63194 - grass/trunk/scripts/i.tasscap - Author: neteler Date: 2014-11-27 * r62026 - grass/trunk: display/d.info include/defs lib/display - neteler Date: 2014-09-17 * r63077 - grass/trunk/gui/wxpython/vdigit - Author: mmetz Date: 2014-11-26 * r62904 - grass/trunk/lib/gis - Author: martinl Date: 2014-11-25 * r62850 - grass/trunk/general/g.parser - Author: glynn Date: 2014-11-21 * r62828 - grass/trunk: display/d.his raster/r.his - Author: wenzeslaus Date: 2014-11-19 * r62776 - grass/trunk/lib/gis - Author: mmetz Date: 2014-11-17 * r62756 - grass/trunk/lib/gis - Author: martinl Date: 2014-11-16 * r62709 - grass/trunk/lib/python/script - Author: wenzeslaus Date: 2014-11-11 This list is incomplete, especially concerning the wxGUI and PyGRASS. Also tracked here: https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.0.1tobebackported Please check, backport where reasonable and delete from the trac Wiki list. We should consider to prepare 7.0.1 in a some weeks time. thanks Markus From neteler at osgeo.org Tue Apr 7 11:17:44 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 7 Apr 2015 20:17:44 +0200 Subject: [GRASS-dev] Next GRASS community sprint In-Reply-To: References: Message-ID: On Tue, Mar 10, 2015 at 9:20 AM, Luca Delucchi wrote: > Hi devs, > > what do you think about organize next GRASS community sprint in Como > after the FOSS4G EU? > Starting the Saturday with the FOSS4G EU code sprint [0] and continue > for some days, maybe until Wednesday 22 Please add yourself to the dedicated page at http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Como_2015#Participation Note: also (power) users are welcome!! thanks Markus > > [0] http://wiki.osgeo.org/wiki/Conference-Europe_2015-Como/Code_sprint > > -- > ciao > Luca > > http://gis.cri.fmach.it/delucchi/ > www.lucadelu.org > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev From mlennert at club.worldonline.be Tue Apr 7 11:39:33 2015 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue, 07 Apr 2015 20:39:33 +0200 Subject: [GRASS-dev] New addon module: i.segment.stats Message-ID: <55242465.20406@club.worldonline.be> Hello everyone, I've added a new module to the addons repository: i.segment.stats [1] which calculates spectral and form statistics for raster segments, typically coming from i.segment or possibly r.clump. It is meant as one part of the general toolchain for object-based image segmentation. It is a simple fronted to v.to.db and r.univar and as such a more KISS complement to Pietro's highly sophisticated v.class.ml. Thanks also to MarkusM for significantly accelerating v.to.db ! The biggest ToDo is to add more variables to characterise segments... Moritz [1] https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment.stats From trac at osgeo.org Tue Apr 7 11:41:53 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 07 Apr 2015 18:41:53 -0000 Subject: [GRASS-dev] [GRASS GIS] #2621: r.random.cells should use NULL instead of 0 (was: r.random.cell should use NULL instead of 0) In-Reply-To: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> References: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> Message-ID: <049.6f4e07768abf27a40e1815a767f4dc01@osgeo.org> #2621: r.random.cells should use NULL instead of 0 ----------------------------+----------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Keywords: r.random.cells | Platform: Unspecified Cpu: Unspecified | ----------------------------+----------------------------------------------- Changes (by neteler): * keywords: => r.random.cells * version: 7.0.0 => svn-releasebranch70 Old description: > It seems that r.random.cell is using 0 to mark empty areas instead of > using proper NULL values. > It is easy fixable by r.nulls call, still it should be fixed. > > If it is a desired behaviour, documentation should be updated to state > it. New description: It seems that r.random.cells is using 0 to mark empty areas instead of using proper NULL values. It is easy fixable by r.null call, still it should be fixed. If it is a desired behaviour, documentation should be updated to state it. -- -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 11:44:06 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 07 Apr 2015 18:44:06 -0000 Subject: [GRASS-dev] [GRASS GIS] #2648: v.concave.hull fails with small number of points Message-ID: <042.8db6d081e448a72a6fac5d9929c0802f@osgeo.org> #2648: v.concave.hull fails with small number of points --------------------------+------------------------------------------------- Reporter: annakrat | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Addons | Version: unspecified Keywords: concave hull | Platform: All Cpu: Unspecified | --------------------------+------------------------------------------------- Tested with 3, 4, 5 points, v.concave.hull fails. Depends on threshold and point configuration, too. {{{ ERROR: Input vector map contains no boundaries. ... ['v.centroids', '--q', 'input=concave_hull_tmp_31390_delaunay_borders_select', 'output=concave_hull_tmp_31390_delaunay_areas_select'] ended with error }}} -- Ticket URL: GRASS GIS From neteler at osgeo.org Tue Apr 7 12:08:41 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 7 Apr 2015 21:08:41 +0200 Subject: [GRASS-dev] [GRASS-user] New addon module: i.segment.stats In-Reply-To: <55242465.20406@club.worldonline.be> References: <55242465.20406@club.worldonline.be> Message-ID: On Tue, Apr 7, 2015 at 8:39 PM, Moritz Lennert wrote: > Hello everyone, > > I've added a new module to the addons repository: i.segment.stats [1] which > calculates spectral and form statistics for raster segments, typically > coming from i.segment or possibly r.clump. ... > [1] > https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.segment.stats Nice! And there is also the beautifully rendered manual page: http://grass.osgeo.org/grass70/manuals/addons/i.segment.stats.html Installation: g.extension i.segment.stats Markus From trac at osgeo.org Tue Apr 7 12:19:53 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 07 Apr 2015 19:19:53 -0000 Subject: [GRASS-dev] [GRASS GIS] #2621: r.random.cells should use NULL instead of 0 In-Reply-To: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> References: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> Message-ID: <049.0b23c611fffe99e4aa255ae1a81542f4@osgeo.org> #2621: r.random.cells should use NULL instead of 0 ----------------------------+----------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Keywords: r.random.cells | Platform: Unspecified Cpu: Unspecified | ----------------------------+----------------------------------------------- Changes (by neteler): * priority: minor => normal Comment: Hopefully fixed in r65021. Please check. TODO: * update manual page example * Backported to relbranch7 -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 15:24:42 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 07 Apr 2015 22:24:42 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults In-Reply-To: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> References: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> Message-ID: <051.b675d5647daaec52419af0b1b85282fe@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by glynn): Replying to [comment:3 pertusus]: > I poked around a bit in gdb, and my first impression is that the error is already in draw_line, it is never checked if x1 could be equal to x2, which means dx = 0, so at line 59, in {{{ y = y1 + (x - x1) * dy / dx; }}} > y is set to nan and the segfault is a consequence of that. > > I have no idea whether x1 and X2 are supposed never to be equal or not. Line 59 is within the "else" clause of the condition {{{ if (fabs(y1 - y2) > fabs(x1 - x2)) { }}} The only way for that condition to be false when fabs(x1-x2) is zero (i.e. x1==x2) is if fabs(y1-y2) is also zero (i.e. y1==y2). IOW, this case only occurs when x1==x2 AND y1==y2, i.e. both endpoints are identical. It should suffice to add {{{ if (x1 == x2 && y1 == y2) return; }}} to the start of that function. Although it's possible that if both differences are very close to zero (e.g. so small as to be denormals), rounding error could result in the dependent variable being garbage, that shouldn't actually cause a problem, as either positive or negative infinity would fail the clip-rectangle test in store_xy(). It's only for NaN where the issue arises. In fact, it may also suffice to invert the logic of the clip-rectangle test, i.e. change {{{ if (x < png.clip_left || x >= png.clip_rite || y < png.clip_top || y >= png.clip_bot) return; }}} to {{{ if (!(x >= png.clip_left && x < png.clip_rite && y >= png.clip_top && y < png.clip_bot)) return; }}} The rationale is that any comparison involving NaN is always false (except for !=, which is always true, even for NaN!=NaN). So a NaN value should fail an "inside" test as well as the current "outside" test. -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 15:39:16 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 07 Apr 2015 22:39:16 -0000 Subject: [GRASS-dev] [GRASS GIS] #312: wxNVIZ prints debug to terminal In-Reply-To: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> References: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> Message-ID: <051.0ac9809a7dd139b039b2af2a5eddddb5@osgeo.org> #312: wxNVIZ prints debug to terminal -----------------------+---------------------------------------------------- Reporter: msieczka | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 6.4.3 Component: wxGUI | Version: svn-releasebranch64 Keywords: digitizer | Platform: All Cpu: All | -----------------------+---------------------------------------------------- Comment(by glynn): Replying to [comment:2 neteler]: > Does anyone know how to intercept GRASS_INFO_MESSAGE() etc to avoid that it gets > printed to the terminal? export GRASS_MESSAGE_FORMAT=silent Alternatively, identify the G_message() calls and change them to G_verbose_message() so that they don't get printed without --verbose. -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 17:13:24 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 00:13:24 -0000 Subject: [GRASS-dev] [GRASS GIS] #312: wxNVIZ prints debug to terminal In-Reply-To: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> References: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> Message-ID: <051.03eea9b1c621da6e2e448461ee78f2dd@osgeo.org> #312: wxNVIZ prints debug to terminal -----------------------+---------------------------------------------------- Reporter: msieczka | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 6.4.3 Component: wxGUI | Version: svn-releasebranch64 Keywords: digitizer | Platform: All Cpu: All | -----------------------+---------------------------------------------------- Comment(by wenzeslaus): Replying to [comment:3 glynn]: > Replying to [comment:2 neteler]: > > Does anyone know how to intercept GRASS_INFO_MESSAGE() etc to avoid that it gets > > printed to the terminal? > > export GRASS_MESSAGE_FORMAT=silent > > Alternatively, identify the G_message() calls and change them to G_verbose_message() so that they don't get printed without --verbose. I don't understand the issue very well. Does this mean that we need to change all `G_message()` calls in the library if there is a chance that the part will be used directly by some GUI application (vdigit, nviz, iclass)? -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 23:06:14 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 06:06:14 -0000 Subject: [GRASS-dev] [GRASS GIS] #2649: r.to.vect diagonals defect fixed Message-ID: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> #2649: r.to.vect diagonals defect fixed -----------------------+---------------------------------------------------- Reporter: byronbest | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Default | Version: unspecified Keywords: | Platform: Unspecified Cpu: x86-64 | -----------------------+---------------------------------------------------- fails to break lines when value changes along diagonals patch for 7.0.0 attached tested in 6.4.3 on Amazon -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 23:16:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 06:16:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2649: r.to.vect diagonals defect fixed In-Reply-To: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> References: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> Message-ID: <052.1f8cabc1f1fc748181a11a87106d645a@osgeo.org> #2649: r.to.vect diagonals defect fixed -----------------------+---------------------------------------------------- Reporter: byronbest | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: unspecified Keywords: | Platform: All Cpu: x86-64 | -----------------------+---------------------------------------------------- Changes (by byronbest): * platform: Unspecified => All * component: Default => Raster -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 7 23:57:37 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 06:57:37 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update Message-ID: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: wxpython | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- 'separator' and 'text' parameter are not updated in the command when an option is selected from the relative dropdown menu. To trig the update, an extra typing in the option textbox is required. -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 01:18:22 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 08:18:22 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults In-Reply-To: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> References: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> Message-ID: <051.ed7307eeb390d942c42cd15bcda9edb9@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by neteler): Replying to [comment:4 glynn]: > IOW, this case only occurs when x1==x2 AND y1==y2, i.e. both endpoints are identical. > > It should suffice to add > > {{{ > if (x1 == x2 && y1 == y2) > return; > }}} > > to the start of that function. > > Although it's possible that if both differences are very close to zero What about comparing the differences against GRASS_EPSILON? -- Ticket URL: GRASS GIS From maris.gis at gmail.com Wed Apr 8 02:47:00 2015 From: maris.gis at gmail.com (Maris Nartiss) Date: Wed, 8 Apr 2015 12:47:00 +0300 Subject: [GRASS-dev] [GRASS-SVN] r64921 - in grass/branches/releasebranch_7_0/gui/wxpython: gui_core lmgr In-Reply-To: References: <20150325202602.1CB253901E5@trac.osgeo.org> Message-ID: 2015-04-04 22:08 GMT+03:00 Martin Landa : > >> More importantly, do we backport features from trunk to release branch 70? > > Small improvements are allowed I would say, we are not in soft freeze. Martin I would tend to say - no. Too many backports are keeping us from pushing faster forward next release and might introduce some issues (trac has quite a lot reports on well intended ideas having side effects). Besides, translations and documentation are suffering from any UI or significant functionality change. With such speed the next GRASS book will be outdated before printing. > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa M?ris. From trac at osgeo.org Wed Apr 8 02:52:35 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 09:52:35 -0000 Subject: [GRASS-dev] [GRASS GIS] #2621: r.random.cells should use NULL instead of 0 In-Reply-To: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> References: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> Message-ID: <049.09be98fbc9755c3c00b8975c56b4f316@osgeo.org> #2621: r.random.cells should use NULL instead of 0 ----------------------------+----------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Keywords: r.random.cells | Platform: Unspecified Cpu: Unspecified | ----------------------------+----------------------------------------------- Comment(by marisn): Replying to [comment:2 neteler]: > * Backport to relbranch7 I would say - no. It changes behaviour of module. 7.0.x shouldn't change such things as it might break some scripts relaying on consistency of 7.0. -- Ticket URL: GRASS GIS From landa.martin at gmail.com Wed Apr 8 05:59:48 2015 From: landa.martin at gmail.com (Martin Landa) Date: Wed, 8 Apr 2015 14:59:48 +0200 Subject: [GRASS-dev] [GRASS-SVN] r64921 - in grass/branches/releasebranch_7_0/gui/wxpython: gui_core lmgr In-Reply-To: References: <20150325202602.1CB253901E5@trac.osgeo.org> Message-ID: 2015-04-03 16:25 GMT+02:00 Martin Landa : >> I suggest to revert r64921 > > I can live with that. done in r65023. Martin -- http://gismentors.cz/mentors/landa From trac at osgeo.org Wed Apr 8 06:36:19 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 13:36:19 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.4352b6afc331b59e49e8e23fccdb0911@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: wxpython | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- Comment(by annakrat): I hoped I can reproduce it on my Ubuntu with wxPython3 but it works for me. What about the 'format' parameter, does it fail too? -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 07:05:48 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 14:05:48 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.843caa21779db8863114635bb281eaa4@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: wxpython | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- Comment(by epifanio): On ubuntu it works fine. The problem is on OSX. I tried the format parameter and it works as expected. the issue are only on "separator" and "text" parameters. Thanks! -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 07:07:56 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 14:07:56 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.9163dcc536f78386605cdd7dfabeb3b5@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: wxpython | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- Comment(by annakrat): Replying to [comment:2 epifanio]: > On ubuntu it works fine. The problem is on OSX. > I tried the format parameter and it works as expected. the issue are only on "separator" and "text" parameters. > Thanks! that's really strange, these all should be the same widgets -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 10:26:54 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 17:26:54 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available Message-ID: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> #2651: Increase maximum number of vector points available -------------------------------+-------------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: unspecified Keywords: vector point data | Platform: Unspecified Cpu: Unspecified | -------------------------------+-------------------------------------------- The current number of points in a imported into a vector data layer appears to be limited to a 32 bit integer ( 2 billion) . You are allowed to import more, but the number of points are indicated with a negative number Not sure if the data set is still valid at that point. The primary use case for this is lidar data. The new USGS standard for landscape LiDAR data collection is QL2 , http://pubs.usgs.gov/tm/11b4/ , roughly 2 points/meter density. The lidar ground points at this density can exceed the 32 bit integer limit in a 1000 km^2 area (31km x 31km). I already have counties in NC, USA with ground point data that exceed this threshold. Newer LiDAR technologies ( Single Photon, Geiger Mode) with collection densities of 20 points/meter are already available, but r.in.lidar may be more suitable for these data sets in the short term. -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 11:25:47 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 18:25:47 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.b5b71ab13e301e92a2751fe061380441@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Changes (by neteler): * keywords: vector point data => lidar, vector point data * version: unspecified => svn-trunk Comment: Replying to [ticket:2651 dnewcomb]: > The current number of points in a imported into a vector data layer appears to be limited to a 32 bit integer ( 2 billion). Isn't this the limit in case of topology being enabled? Did you try to disable topology during import? -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 12:11:05 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 19:11:05 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.9d248fd734daa56ef80aa4b70b51f231@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by dnewcomb): Topology was disabled. Attribute table was not built. Looking back, I am running an svn snapshot from 1-10-2015, was this addressed before the final release? -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 12:11:59 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 19:11:59 -0000 Subject: [GRASS-dev] [GRASS GIS] #2621: r.random.cells should use NULL instead of 0 In-Reply-To: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> References: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> Message-ID: <049.f4ae1aa736229e025e37b76bfb5f99f5@osgeo.org> #2621: r.random.cells should use NULL instead of 0 ----------------------------+----------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Keywords: r.random.cells | Platform: Unspecified Cpu: Unspecified | ----------------------------+----------------------------------------------- Comment(by neteler): G7.1 manual updated in r65024. Replying to [comment:3 marisn]: > Replying to [comment:2 neteler]: > > * Backport to relbranch7 > I would say - no. It changes behaviour of module. 7.0.x shouldn't change such things as it might break some scripts relaying on consistency of 7.0. Maybe. However, the 7.0 manual states "The cells are numbered from 1 to the numbers of cells generated." which is not true. -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 12:15:03 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 19:15:03 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.561ce4588e0b8df4dfcd1403bef526f2@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by neteler): Replying to [comment:2 dnewcomb]: > Topology was disabled. Attribute table was not built. OK - this is an important information. > Looking back, I am running an svn snapshot from 1-10-2015, was this addressed before the final release? No idea but there were definitely important vector fixes implemented after that date: https://trac.osgeo.org/grass/log/grass/trunk/lib/vector -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 13:22:26 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 20:22:26 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.05f020c6eb5d97c8e67918f66ea41600@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by dnewcomb): Will upgrade to latest weekly and report back -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 15:29:39 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 08 Apr 2015 22:29:39 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.592e15381f18d93a26e54792f26b5fc5@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: wxpython | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- Comment(by epifanio): I attached a short vide to show the behaviour. I agree it's strange and they are all the same type of widget. http://144.76.93.231/shared/debugging/grassgui_v-in-ascii.mp4 -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 19:42:03 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 02:42:03 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.30056914a4d67e05fa5646128e7d30f8@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: wxpython | Platform: MacOSX Cpu: OSX/Intel | -----------------------+---------------------------------------------------- Comment(by annakrat): Replying to [comment:4 epifanio]: > I attached a short vide to show the behaviour. I agree it's strange and they are all the same type of widget. > > http://144.76.93.231/shared/debugging/grassgui_v-in-ascii.mp4 Please try r65027 in trunk. -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 19:54:47 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 02:54:47 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.ad531ab00e024ab3bf4976a19b9e5080@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: closed Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Resolution: fixed | Keywords: wxpython Platform: MacOSX | Cpu: OSX/Intel -----------------------+---------------------------------------------------- Changes (by epifanio): * status: new => closed * resolution: => fixed Comment: It works grear, thank you! -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 19:57:01 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 02:57:01 -0000 Subject: [GRASS-dev] [GRASS GIS] #2650: v.in.ascii - dropdown menu - gui components doesn't get update In-Reply-To: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> References: <042.603fb79fcf1b7958ebaa86450fcac01f@osgeo.org> Message-ID: <051.36f5663960a9e5362be4141eb914bbe4@osgeo.org> #2650: v.in.ascii - dropdown menu - gui components doesn't get update -----------------------+---------------------------------------------------- Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: closed Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Resolution: fixed | Keywords: wxpython Platform: MacOSX | Cpu: OSX/Intel -----------------------+---------------------------------------------------- Comment(by annakrat): Backported in r65028. -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 20:09:28 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 03:09:28 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector In-Reply-To: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> References: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> Message-ID: <051.488c66aedd6b92308cebf3bf406220a5@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector ---------------------------------+------------------------------------------ Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit, wxPython 3 | Platform: MacOSX Cpu: Unspecified | ---------------------------------+------------------------------------------ Comment(by epifanio): When the gui freeze i can't see anything printed in the shell and all the gui windows are not functionals. The only way is to force quite it. Is there a way to debug this ? perhaps add some print statement at some point in the wxpytho/v.digit code to see where it blocks ? -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 20:19:28 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 03:19:28 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector In-Reply-To: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> References: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> Message-ID: <051.52b44a3514c418b23ca69750afe5cccf@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector ---------------------------------+------------------------------------------ Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit, wxPython 3 | Platform: MacOSX Cpu: Unspecified | ---------------------------------+------------------------------------------ Comment(by annakrat): Replying to [comment:2 epifanio]: > When the gui freeze i can't see anything printed in the shell and all the gui windows are not functionals. The only way is to force quite it. Is there a way to debug this ? perhaps add some print statement at some point in the wxpytho/v.digit code to see where it blocks ? In gui/wxpython/dbmgr/dialogs.py OnSubmit method. I can't see anything what could be causing the problem there so far. I am unable to test it on Mac now. Does only Submit button causes the problems, or Close as well? -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 20:27:03 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 03:27:03 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector In-Reply-To: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> References: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> Message-ID: <051.0ff2de73b73d43724be7c00c4f116194@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector ---------------------------------+------------------------------------------ Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit, wxPython 3 | Platform: MacOSX Cpu: Unspecified | ---------------------------------+------------------------------------------ Comment(by epifanio): After digitizing a first feature and the dialog to submit or cancel is shown. Anything i press (close, cancel or submit) will freeze the gui. I'll try to look into gui/wxpython/dbmgr/dialogs.py -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 20:36:04 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 03:36:04 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector In-Reply-To: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> References: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> Message-ID: <051.590c828b4659400ee5aef4726e5635bb@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector ---------------------------------+------------------------------------------ Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit, wxPython 3 | Platform: MacOSX Cpu: Unspecified | ---------------------------------+------------------------------------------ Comment(by annakrat): Replying to [comment:4 epifanio]: > After digitizing a first feature and the dialog to submit or cancel is shown. Anything i press (close, cancel or submit) will freeze the gui. I'll try to look into gui/wxpython/dbmgr/dialogs.py I suspect there is problem with modality of the dialog, in the case of this dialog it is implemented in a weird way, you might want to look also in vdigit/mapwindow.py search for DisplayAttributesDialog. -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 8 20:47:57 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 03:47:57 -0000 Subject: [GRASS-dev] [GRASS GIS] #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector In-Reply-To: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> References: <042.1bd025686f2fb1b7e731745a96abc8d9@osgeo.org> Message-ID: <051.a111ebfca5d3ec7cf400e342c1252e6b@osgeo.org> #2644: osx - wxpython 3 64 bit - v.digit gui freeze when digitizing new vector ---------------------------------+------------------------------------------ Reporter: epifanio | Owner: grass-dev@? Type: defect | Status: new Priority: critical | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: v.digit, wxPython 3 | Platform: MacOSX Cpu: Unspecified | ---------------------------------+------------------------------------------ Comment(by epifanio): i made a video to show the issue, i'll look into the files to see if i can see something, thanks! http://144.76.93.231/shared/debugging/v_digit.mp4 -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 9 04:42:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 11:42:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.1afc5fea4942c68a07734c8a71bf3013@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by dnewcomb): Installed 4-4-15 weekly svn snapshot and started import of las file with roughly 2.4 billion points. v.in.lidar is reporting scanning -1.87 billion points on import. -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 9 05:09:14 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 12:09:14 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.e07b65b5d51d7e020be9bab279ebae81@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by marisn): Could you, please, copy / paste exact message text? It could be as simple as wrong formatting character used while printing message or overflowing counter used just to print progress. -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 9 05:40:07 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 12:40:07 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.17a3e1c8f42971c4964977a31912a173@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by dnewcomb): Replying to [comment:6 marisn]: > Could you, please, copy / paste exact message text? > It could be as simple as wrong formatting character used while printing message or overflowing counter used just to print progress. v.in.lidar -t -o -b input=/media/Seagate Expansion Drive/BladenCoNC/bladen_ground0.laz output=bladen_ground_pts Over-riding projection check Scanning -1879965037 points... When I ran v.in.lidar on the previous version of GRASS 7 that I was using, I ran v.info on the resulting vector data set and go the same number for the number of points . Here is the info on the lidar file: newcomb at IFW4FO-RAL-SGIS:/media/Seagate Expansion Drive/BladenCoNC$ ~/lastools/lastools/bin/lasinfo bladen_ground0.laz reporting all LAS header entries: file signature: 'LASF' file source ID: 0 global_encoding: 1 project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000 version major.minor: 1.3 system identifier: 'LAStools (c) by Martin Isenburg' generating software: 'lasmerge (version 131210)' file creation day/year: 252/2014 header size: 235 offset to point data: 345 number var. length records: 1 point data format: 3 point data record length: 34 number of point records: 2415002259 number of points by return: 1503313306 704621650 204714902 2216754 135647 scale factor x y z: 0.01 0.01 0.01 offset x y z: -0 -0 -0 min x y z: 2030000.00 225000.00 3.92 max x y z: 2244999.99 404999.99 174.24 -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 9 05:59:10 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 12:59:10 -0000 Subject: [GRASS-dev] [GRASS GIS] #2651: Increase maximum number of vector points available In-Reply-To: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> References: <042.2e1b6d459ee67664ea5935fb560131a4@osgeo.org> Message-ID: <051.b84a2e77de9ae6023ee719cc06c82a08@osgeo.org> #2651: Increase maximum number of vector points available --------------------------------------+------------------------------------- Reporter: dnewcomb | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: lidar, vector point data | Platform: Unspecified Cpu: Unspecified | --------------------------------------+------------------------------------- Comment(by dnewcomb): Replying to [comment:7 dnewcomb]: Looking back, this seems to be a duplication of this ticket, which I forgotten I had submitted http://trac.osgeo.org/grass/ticket/2472 > Replying to [comment:6 marisn]: > > Could you, please, copy / paste exact message text? > > It could be as simple as wrong formatting character used while printing message or overflowing counter used just to print progress. > > v.in.lidar -t -o -b input=/media/Seagate Expansion Drive/BladenCoNC/bladen_ground0.laz output=bladen_ground_pts > Over-riding projection check > Scanning -1879965037 points... > > When I ran v.in.lidar on the previous version of GRASS 7 that I was using, I ran v.info on the resulting vector data set and go the same number for the number of points . > > Here is the info on the lidar file: > > newcomb at IFW4FO-RAL-SGIS:/media/Seagate Expansion Drive/BladenCoNC$ ~/lastools/lastools/bin/lasinfo bladen_ground0.laz > reporting all LAS header entries: > file signature: 'LASF' > file source ID: 0 > global_encoding: 1 > project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000 > version major.minor: 1.3 > system identifier: 'LAStools (c) by Martin Isenburg' > generating software: 'lasmerge (version 131210)' > file creation day/year: 252/2014 > header size: 235 > offset to point data: 345 > number var. length records: 1 > point data format: 3 > point data record length: 34 > number of point records: 2415002259 > number of points by return: 1503313306 704621650 204714902 2216754 135647 > scale factor x y z: 0.01 0.01 0.01 > offset x y z: -0 -0 -0 > min x y z: 2030000.00 225000.00 3.92 > max x y z: 2244999.99 404999.99 174. -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 9 12:04:05 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 19:04:05 -0000 Subject: [GRASS-dev] [GRASS GIS] #312: wxNVIZ prints debug to terminal In-Reply-To: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> References: <042.8e58b58132d44f20d6c2d03c62eb764f@osgeo.org> Message-ID: <051.74317c67987bfafaf55eb1d89a53a2e9@osgeo.org> #312: wxNVIZ prints debug to terminal -----------------------+---------------------------------------------------- Reporter: msieczka | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 6.4.3 Component: wxGUI | Version: svn-releasebranch64 Keywords: digitizer | Platform: All Cpu: All | -----------------------+---------------------------------------------------- Comment(by glynn): Replying to [comment:4 wenzeslaus]: > > Alternatively, identify the G_message() calls and change them to G_verbose_message() so that they don't get printed without --verbose. > > I don't understand the issue very well. Does this mean that we need to change all `G_message()` calls in the library if there is a chance that the part will be used directly by some GUI application (vdigit, nviz, iclass)? First, should GUI programs be different to non-GUI programs in this regard? The issue is that library functions are generating messages, meaning that any program which uses those functions will generate messages. It's debatable whether library functions have enough context to decide which messages are appropriate. Vlib is particularly noisy in this regard. I count 113 calls to G_message() in lib/*/*.c (excluding test suites). 59 of those (more than half) are in Vlib. The other issue seems to be that GUI-format messages are being written to the terminal, which suggests an issue in the way that the program is started (i.e. something is executing it with GRASS_MESSAGE_FORMAT=gui but not capturing its output; the point of GRASS_MESSAGE_FORMAT=gui is to use a machine-readable format so that a GUI can process the messages). -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 9 12:06:56 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 09 Apr 2015 19:06:56 -0000 Subject: [GRASS-dev] [GRASS GIS] #2643: d.vect png with icon=basic/circle and long paths segfaults In-Reply-To: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> References: <042.f1e0804a71b4df0dd2168416e83cbde1@osgeo.org> Message-ID: <051.6bf6b19a52fdf8764d57aa117244c037@osgeo.org> #2643: d.vect png with icon=basic/circle and long paths segfaults ----------------------+----------------------------------------------------- Reporter: pertusus | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Display | Version: svn-releasebranch70 Keywords: | Platform: Linux Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by glynn): Fudge factors are best avoided. And probably unnecessary here; this issue appears to be limited to the specific case where both endpoints are exactly equal. -- Ticket URL: GRASS GIS From nik at nikosalexandris.net Thu Apr 9 14:32:57 2015 From: nik at nikosalexandris.net (Nikos Alexandris) Date: Fri, 10 Apr 2015 00:32:57 +0300 Subject: [GRASS-dev] Linke turbidity in r.sun.daily In-Reply-To: <4b4e5d77381ad079785d7a91022cb387@nikosalexandris.net> References: <20bf51341a86daf957e4938bc1e5c931@nikosalexandris.net> <8d5700ca24d175e6fdc54cd15dc5ccca@nikosalexandris.net> <20150327211412.GA4416@tpx1c2g> <73582c90c43bd73be202af2cc7d4c583@nikosalexandris.net> <4b4e5d77381ad079785d7a91022cb387@nikosalexandris.net> Message-ID: <20150409213257.GB15370@tpx1c2g> @Vaclav, Anna: ping May I push changes for the r.sun.daily script in the add-ons repository? Nikos ps- What are the team's "feelings" about switching the project to git, at some point? * Nikos Alexandris [2015-03-28 12:49:39 +0200]: > Vaclav Petras: > > >>> It seems you removed the option to add timestamps without > >>> registering to > >>> temporal database. I would just leave the else there. (You may want > >>> to > >>> create timestamps but not register or register later.) > > >> Misjudgement, lead by the comment "...or something in GRASS6.x". > >> Added > >> back. > > Nikos Alexandris: > > > I didn't test this carefully, seems it doesn't work (for me). ToDo. > > It works for daily maps. It doesn't, of course, for example when > requesting 'glob_rad=' which returns the sum of all requested daily > maps. I know, we have the t.* stuff, which is the way to get monthly > maps or else. > > However, it would be nice if we can make it more easy to use, for > example, monthly "Linke T" maps. Say, for day 1 to day 31 use > linke_January, for day 32 to day... use linke_February and so on. -- > Comments? > > Nikos > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -- Nikos Alexandris | Remote Sensing Scientist, Dr Themidos 3, 42100, Trikala, Greece GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 From wenzeslaus at gmail.com Thu Apr 9 18:13:56 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Thu, 9 Apr 2015 21:13:56 -0400 Subject: [GRASS-dev] Linke turbidity in r.sun.daily In-Reply-To: <20150409213257.GB15370@tpx1c2g> References: <20bf51341a86daf957e4938bc1e5c931@nikosalexandris.net> <8d5700ca24d175e6fdc54cd15dc5ccca@nikosalexandris.net> <20150327211412.GA4416@tpx1c2g> <73582c90c43bd73be202af2cc7d4c583@nikosalexandris.net> <4b4e5d77381ad079785d7a91022cb387@nikosalexandris.net> <20150409213257.GB15370@tpx1c2g> Message-ID: On Thu, Apr 9, 2015 at 5:32 PM, Nikos Alexandris wrote: > @Vaclav, Anna: ping > > May I push changes for the r.sun.daily script in the add-ons repository? > > Sure, you consulted the changes and you have the access, so you are in charge now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitabh.tiwari27 at gmail.com Thu Apr 9 18:32:43 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Fri, 10 Apr 2015 07:02:43 +0530 Subject: [GRASS-dev] Multimedia Data mining on RSI Images-Phase 1-Documented. Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PARM.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 448295 bytes Desc: not available URL: From neteler at osgeo.org Thu Apr 9 23:55:15 2015 From: neteler at osgeo.org (Markus Neteler) Date: Fri, 10 Apr 2015 08:55:15 +0200 Subject: [GRASS-dev] Multimedia Data mining on RSI Images-Phase 1-Documented. In-Reply-To: References: Message-ID: On Fri, Apr 10, 2015 at 3:32 AM, Amitabh wrote: Could you please describe how GRASS GIS is involved and why it is called "Multimedia..."? Markus From peter.zamb at gmail.com Fri Apr 10 07:00:18 2015 From: peter.zamb at gmail.com (Pietro) Date: Fri, 10 Apr 2015 16:00:18 +0200 Subject: [GRASS-dev] mathjax support for GRASS manual pages Message-ID: Dear devs, What do you think if we start supporting mathjax on the html webpages? Please read more on mathjax here: http://www.mathjax.org/ And then we should be able to add formulas on our html page with: $\frac{n!}{k!(n-k)!} = \binom{n}{k}$ To do this we should modify the header in the manual html pages. Any thoughts? Pietro From amitabh.tiwari27 at gmail.com Fri Apr 10 08:57:47 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Fri, 10 Apr 2015 21:27:47 +0530 Subject: [GRASS-dev] Multimedia Data mining on RSI Images-Phase 1-Documented. In-Reply-To: References: Message-ID: *Why Multimedia in the title?* see there are two types of data mining algorithms : 1. Textual Data mining algorithms(K-means,apriori,K-nn etc.) 2. Multimedia data mining algorithms (for audio,video frames,images,full motion videos etc.) This implementation of mine belongs to the second category. *Contribution to GRASS GIS:* I studied this software a lot and analyzed it from the perspective of geo-spatial researchers.Being an active member of several geo-spatial forums,I analyzed the several products available in the market available for processing of satellite images.Now in order to be on the top in a long run,we have to always find a cutting edge over the others.This feature of mining satellite images at bit level across different light bands is not provided by a single software.On top of that this technology was introduced in the market just 1-1/2 years ago in an IEEE paper by Qin Ding and william perrizo which was recognized as the best technological advancement in the field of geo-processing. Please provide your feedback on the same. Regards, -Amitabh On Fri, Apr 10, 2015 at 12:25 PM, Markus Neteler wrote: > On Fri, Apr 10, 2015 at 3:32 AM, Amitabh > wrote: > > Could you please describe how GRASS GIS is involved and why it is > called "Multimedia..."? > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucadeluge at gmail.com Fri Apr 10 22:20:35 2015 From: lucadeluge at gmail.com (Luca Delucchi) Date: Sat, 11 Apr 2015 07:20:35 +0200 Subject: [GRASS-dev] mathjax support for GRASS manual pages In-Reply-To: References: Message-ID: Il 10/apr/2015 16:00, "Pietro" ha scritto: > > Dear devs, > Dear all, > What do you think if we start supporting mathjax on the html webpages? > > Please read more on mathjax here: http://www.mathjax.org/ > > And then we should be able to add formulas on our html page with: > $\frac{n!}{k!(n-k)!} = \binom{n}{k}$ > > To do this we should modify the header in the manual html pages. > Any thoughts? > I like the idea > Pietro > Ciao Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From glynn at gclements.plus.com Sat Apr 11 13:30:19 2015 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat, 11 Apr 2015 21:30:19 +0100 Subject: [GRASS-dev] mathjax support for GRASS manual pages In-Reply-To: References: Message-ID: <21801.33883.629658.571961@cerise.gclements.plus.com> Pietro wrote: > What do you think if we start supporting mathjax on the html webpages? The main drawbacks of doing so are: 1. It's likely to mess up the nroff manual pages which are generated from the HTML versions (unless someone's planning on adding code to g.html2man to recognise the mathjax portions and re-write them using eqn syntax). 2. It won't work with HTML viewers which don't support JavaScript (AFAICT, the wx.html control used by wxGUI doesn't). Or images (e.g. lynx/links). 3. Network access is required to read the manual pages, even when stored locally. This also has privacy implications. -- Glynn Clements From p.vanbreugel at gmail.com Mon Apr 13 01:31:05 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Mon, 13 Apr 2015 10:31:05 +0200 Subject: [GRASS-dev] Error messages when installing addons Message-ID: I updated a number of extensions, all which installed successfully. However, for four (g.cloud, r.mcda.roughset, r.futures, v.area.stats) I got some error messages. Not sure they are relevant, but though I might as well report them. I am running GRASS dev (rev 65027) on Linux (Ubuntu 14.04). *g.cloud* g.extension extension=g.cloud operation=add WARNING: Extension already installed. Re-installing... Fetching from GRASS-Addons SVN repository (be patient)... Compiling... Makefile:16: warning: overriding commands for target `/tmp/tmpIdTTFc/g.cloud/etc/g.cloud' /usr/local/grass7/grass-7.1.svn/include/Make/ScriptRules.mak e:19: warning: ignoring old commands for target `/tmp/tmpIdTTFc/g.cloud/etc/g.cloud' Installing... Makefile:16: warning: overriding commands for target `/tmp/tmpIdTTFc/g.cloud/etc/g.cloud' /usr/local/grass7/grass-7.1.svn/include/Make/ScriptRules.mak e:19: warning: ignoring old commands for target `/tmp/tmpIdTTFc/g.cloud/etc/g.cloud' Updating addons metadata file... Installation of successfully finished *r.mcda.roughset* g.extension extension=r.mcda.roughset operation=add WARNING: Extension already installed. Re-installing... Fetching from GRASS-Addons SVN repository (be patient)... Compiling... WARNING: BUG in option name, 'outputMap' is not valid WARNING: BUG in option name, 'outputTxt' is not valid Installing... Updating addons metadata file... Installation of successfully finished *r.futures* g.extension extension=r.futures operation=add WARNING: Extension already installed. Re-installing... Fetching from GRASS-Addons SVN repository (be patient)... Compiling... main.cpp: In function ?int main(int, char**)?: main.cpp:2512:67: warning: suggest parentheses around assignment used as truth value [-Wparentheses] if (pPtr = strchr(inBuff, ',')) { ^ main.cpp: In function ?void findAndSortProbsAll(t_Landscape*, t_Params*, int)?: main.cpp:2663:55: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] pLandscape->asUndevs[id].size()) ^ main.cpp: In function ?int readData(t_Landscape*, t_Params*)?: main.cpp:639:71: warning: ?iVal? may be used uninitialized in this function [-Wmaybe-uninitialized] pLandscape->asCells[i].bUndeveloped = iVal; ^ main.cpp:689:52: warning: ?y? may be used uninitialized in this function [-Wmaybe-uninitialized] G_message(_("x=%d y=%d"), x, y); ^ main.cpp: In function ?int main(int, char**)?: main.cpp:2426:21: warning: ?seed_value? may be used uninitialized in this function [-Wmaybe-uninitialized] srand(seed_value); ^ Installing... Updating addons metadata file... Installation of successfully finished *v.area.stats* g.extension extension=v.area.stats operation=add WARNING: Extension already installed. Re-installing... Fetching from GRASS-Addons SVN repository (be patient)... Compiling... export.c: In function ?export2csv?: export.c:97:4: warning: format not a string literal and no format arguments [-Wformat-security] printf(buf); ^ Installing... Updating addons metadata file... Installation of successfully finished -------------- next part -------------- An HTML attachment was scrubbed... URL: From ychemin at gmail.com Mon Apr 13 10:01:43 2015 From: ychemin at gmail.com (Yann Chemin) Date: Mon, 13 Apr 2015 19:01:43 +0200 Subject: [GRASS-dev] distributed computing: block access in raster lib Message-ID: Hi, I am looking into distributed processing of raster data in GRASS, I found this in i.smap/read_block.c Would that be a good idea to include something similar into the raster lib API? #include #include #include #include #include "bouman.h" #include "region.h" int read_block(DCELL *** img, /* img[band][row[col] */ struct Region *region, struct files *files) { int band, row, col; for (band = 0; band < files->nbands; band++) { for (row = region->ymin; row < region->ymax; row++) { Rast_get_d_row(files->band_fd[band], files->cellbuf, row); for (col = region->xmin; col < region->xmax; col++) img[band][row][col] = files->cellbuf[col]; } } return 0; } Cheers, Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Mon Apr 13 10:22:46 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 13 Apr 2015 17:22:46 -0000 Subject: [GRASS-dev] [GRASS GIS] #2523: wxGUI digitiser - GRASS 7.0.0beta4 / persists in 7.1.svn (r64690M) In-Reply-To: <038.86eb3263b7fa15d2069c9a0d34f41735@osgeo.org> References: <038.86eb3263b7fa15d2069c9a0d34f41735@osgeo.org> Message-ID: <047.e5d15ccfa87c834d064fb8ed7345fcc7@osgeo.org> #2523: wxGUI digitiser - GRASS 7.0.0beta4 / persists in 7.1.svn (r64690M) -----------------------------+---------------------------------------------- Reporter: jeir | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: digitizer, .gxw | Platform: MacOSX Cpu: OSX/Intel | -----------------------------+---------------------------------------------- Comment(by jeir): I add the following as it relates to the vector digitizer: Problem: Unstable vector digitizer Undo Location: nc_spm_08_grass7 Mapset: user1 User - Copy roadsmajor from PERMANENT as test_roadsmajor User - Activated vector digitizer, added a few vector points - pressed Undo button, wxgui Map Display window disappears and this message appears: Python quit unexpectedly while using the libgrass_vector.7.1.svn.dylib plug-in Terminal session window after Map Display diappears: Welcome to GRASS GIS 7.1.svn (r64690M) GRASS GIS homepage: http://grass.osgeo.org This version running through: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c If required, restart the GUI with: g.gui wxpython When ready to quit enter: exit Launching GUI in the background, please wait... GRASS 7.1.svn (nc_spm_08_grass7):~ > WARNING: No metadata file available GRASS_INFO_WARNING(3065,1): Coor file of vector map is larger than it should be (2403 bytes excess) GRASS_INFO_END(3065,1) User - Responded: 1. Exit GRASS 2. Restart GRASS, same location and mapset User - Activated vector digitizer - this message appears: Digitizer error Topology for vector map GUI in the background, please wait... GRASS 7.1.svn (nc_spm_08_grass7):~ > WARNING: No metadata file available GRASS_INFO_WARNING(3256,1): Coor file of vector map is larger than it should be (9508 bytes excess) GRASS_INFO_END(3256,1) --- With my own data, I have experienced total disappearance from mapset - of the active map during digitization session Other problems I have encountered, see: Ticket #2523 above -- Ticket URL: GRASS GIS From mlennert at club.worldonline.be Tue Apr 14 01:05:36 2015 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue, 14 Apr 2015 10:05:36 +0200 Subject: [GRASS-dev] [GRASS-user] v.isochrones : error message In-Reply-To: <1428953154411-5201157.post@n6.nabble.com> References: <1428185015224-5199989.post@n6.nabble.com> <1428231237171-5200009.post@n6.nabble.com> <5521B111.1010302@club.worldonline.be> <5521C224.3030504@club.worldonline.be> <1428835537311-5200944.post@n6.nabble.com> <552B7A97.9000205@club.worldonline.be> <1428953154411-5201157.post@n6.nabble.com> Message-ID: <552CCA50.8000105@club.worldonline.be> On 13/04/15 21:25, image93 wrote: > Hello, > > I removed the current extension and then reinstall it > > g.extension v.isochrones op=remove -f > g.extension v.isochrones op=add > > i'am working with windows 7 32 bit OS. > I found the path pointing to the v.isochrones.bat : > C:\Users\laurent\AppData\Roaming\GRASS7\addons\bin > > Moreover, when i launch the v.isochrones GUI , METHOD and COST_COLUMN > parameters are still not available. The installation of the new extension > does not work on my side. g.extension is still reinstalled the old version. > Is this a problem of repostory? There are several the repositories for Grass > extensions? i don't know. I found it: for grass70, the repository is http://wingrass.fsv.cvut.cz/grass70/addons/grass-7.0.0/ and the v.isochrones there is still the old version. Martin, shouldn't updates to addons in addons/grass7 automatically be updated for this repository as well ? Or do we have a special grass70 addons repository ? Laurent, what you can do while this is sorted out is to download v.isochrones.py from https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.isochrones/v.isochrones.py Click on 'Original Format' at the bottom of the page and overwrite the existing v.isochrones.py on your machine with this. Attention: this is v.isochrones.py, not v.isochrones.bat. You can open the latter in a text editor to check where the former is located. Moritz From trac at osgeo.org Tue Apr 14 16:13:07 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 14 Apr 2015 23:13:07 -0000 Subject: [GRASS-dev] [GRASS GIS] #2652: v.in.e00 Message-ID: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> #2652: v.in.e00 ------------------------+--------------------------------------------------- Reporter: templar112 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Vector | Version: 7.0.0 Keywords: | Platform: MSWindows 8 Cpu: x86-64 | ------------------------+--------------------------------------------------- I'm new to Grass GIS, but it appears that the v.in.e00 script has not been updated to match the new input parameters format. I downloaded an E00 file from http://www.geocomm.com/ just as a test to see if I could import some data. The input parameters it expects are as follows: options['file'] which should be options['input'] options['vect'] which should be options['output'] Also, the script requires the following additional files: avcimport.exe e00conv.exe The former file exists under the "extrabin" folder, but I had to download the e00conv binary myself. Maybe it should be included as well? The next issue is the following line: #try_remove(info) It says that info is not a valid global object or something like that. Finally, the following statement also doesn't work: # write cmd history: grass.vector_history(name) It complains about vector_history not being a valid function. I don't have the expertise to fix this, but maybe some with python and Grass knowledge can! :) -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 14 18:44:58 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 15 Apr 2015 01:44:58 -0000 Subject: [GRASS-dev] [GRASS GIS] #2652: v.in.e00 In-Reply-To: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> References: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> Message-ID: <053.93f369dc61b4a755a3cdcbc8f15c5e85@osgeo.org> #2652: v.in.e00 ------------------------+--------------------------------------------------- Reporter: templar112 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Vector | Version: 7.0.0 Keywords: | Platform: MSWindows 8 Cpu: x86-64 | ------------------------+--------------------------------------------------- Comment(by annakrat): I fixed it in r65055 in trunk. Could you test? Or give me e00 file to test? -- Ticket URL: GRASS GIS From neteler at osgeo.org Tue Apr 14 23:08:58 2015 From: neteler at osgeo.org (Markus Neteler) Date: Wed, 15 Apr 2015 08:08:58 +0200 Subject: [GRASS-dev] [GRASS-user] v.isochrones : error message In-Reply-To: <552CCA50.8000105@club.worldonline.be> References: <1428185015224-5199989.post@n6.nabble.com> <1428231237171-5200009.post@n6.nabble.com> <5521B111.1010302@club.worldonline.be> <5521C224.3030504@club.worldonline.be> <1428835537311-5200944.post@n6.nabble.com> <552B7A97.9000205@club.worldonline.be> <1428953154411-5201157.post@n6.nabble.com> <552CCA50.8000105@club.worldonline.be> Message-ID: On Tue, Apr 14, 2015 at 10:05 AM, Moritz Lennert wrote: > On 13/04/15 21:25, image93 wrote: ... >> Is this a problem of repostory? There are several the repositories for >> Grass extensions? i don't know. > > > I found it: for grass70, the repository is > http://wingrass.fsv.cvut.cz/grass70/addons/grass-7.0.0/ and the v.isochrones > there is still the old version. Seems to be solved: v.isochrones.zip14-Apr-2015 04:27 133K I suppose that the job runs once per week, not daily. You may try the installation again. Markus From mlennert at club.worldonline.be Tue Apr 14 23:51:32 2015 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed, 15 Apr 2015 08:51:32 +0200 Subject: [GRASS-dev] [GRASS-user] v.isochrones : error message In-Reply-To: References: <1428185015224-5199989.post@n6.nabble.com> <1428231237171-5200009.post@n6.nabble.com> <5521B111.1010302@club.worldonline.be> <5521C224.3030504@club.worldonline.be> <1428835537311-5200944.post@n6.nabble.com> <552B7A97.9000205@club.worldonline.be> <1428953154411-5201157.post@n6.nabble.com> <552CCA50.8000105@club.worldonline.be> Message-ID: <552E0A74.8070403@club.worldonline.be> On 15/04/15 08:08, Markus Neteler wrote: > On Tue, Apr 14, 2015 at 10:05 AM, Moritz Lennert > wrote: >> On 13/04/15 21:25, image93 wrote: > ... >>> Is this a problem of repostory? There are several the repositories for >>> Grass extensions? i don't know. >> >> >> I found it: for grass70, the repository is >> http://wingrass.fsv.cvut.cz/grass70/addons/grass-7.0.0/ and the v.isochrones >> there is still the old version. > > Seems to be solved: > > v.isochrones.zip14-Apr-2015 04:27 133K This is not the correct version. I don't know where the source for this package is, but if you look here: http://wingrass.fsv.cvut.cz/grass71/addons/grass-7.1.svn/ you'll see v.isochrones.zip 14-Apr-2015 04:27 214K Note the difference in size. And if you look inside, then you can see that the v.isochrones.py in the grass70 version is not the same as in the grass71 version. The latter is the one which is currently in svn. Moritz From neteler at osgeo.org Wed Apr 15 01:15:41 2015 From: neteler at osgeo.org (Markus Neteler) Date: Wed, 15 Apr 2015 10:15:41 +0200 Subject: [GRASS-dev] [GRASS-user] v.isochrones : error message In-Reply-To: <552E0A74.8070403@club.worldonline.be> References: <1428185015224-5199989.post@n6.nabble.com> <1428231237171-5200009.post@n6.nabble.com> <5521B111.1010302@club.worldonline.be> <5521C224.3030504@club.worldonline.be> <1428835537311-5200944.post@n6.nabble.com> <552B7A97.9000205@club.worldonline.be> <1428953154411-5201157.post@n6.nabble.com> <552CCA50.8000105@club.worldonline.be> <552E0A74.8070403@club.worldonline.be> Message-ID: Hi Martin, On Wed, Apr 15, 2015 at 8:51 AM, Moritz Lennert wrote: > On 15/04/15 08:08, Markus Neteler wrote: >> >> On Tue, Apr 14, 2015 at 10:05 AM, Moritz Lennert >> wrote: >>> >>> On 13/04/15 21:25, image93 wrote: >> >> ... >>>> >>>> Is this a problem of repostory? There are several the repositories for >>>> Grass extensions? i don't know. >>> >>> >>> >>> I found it: for grass70, the repository is >>> http://wingrass.fsv.cvut.cz/grass70/addons/grass-7.0.0/ and the >>> v.isochrones >>> there is still the old version. >> >> >> Seems to be solved: >> >> v.isochrones.zip14-Apr-2015 04:27 133K > > > This is not the correct version. I don't know where the source for this > package is, but if you look here: > > http://wingrass.fsv.cvut.cz/grass71/addons/grass-7.1.svn/ > > you'll see > > v.isochrones.zip 14-Apr-2015 04:27 214K > > > Note the difference in size. And if you look inside, then you can see that > the v.isochrones.py in the grass70 version is not the same as in the grass71 > version. The latter is the one which is currently in svn. ... could you please check if the 7.0.0 addon script is operating properly on your server? thanks Markus From trac at osgeo.org Wed Apr 15 02:22:46 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 15 Apr 2015 09:22:46 -0000 Subject: [GRASS-dev] [GRASS GIS] #2621: r.random.cells should use NULL instead of 0 In-Reply-To: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> References: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> Message-ID: <049.7821012e46165cfa6406ac5dfdc92cf8@osgeo.org> #2621: r.random.cells should use NULL instead of 0 ----------------------------+----------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Keywords: r.random.cells | Platform: Unspecified Cpu: Unspecified | ----------------------------+----------------------------------------------- Comment(by marisn): Replying to [comment:4 neteler]: > Maybe. However, the 7.0 manual states "The cells are numbered from 1 to the > numbers of cells generated." which is not true. > Then the manual needs to be fixed. (It also doesn't state that empty cells have NULLs thus manual is not contradicting current behaviour.) How about adding a simple sentence "Empty cells are marked with 0 (will be changed to NULL in GRASS GIS 7.1.0 release)."? I would say - fix documentation, add to GRASS 7.1 changes and close this issue. -- Ticket URL: GRASS GIS From landa.martin at gmail.com Wed Apr 15 04:58:12 2015 From: landa.martin at gmail.com (Martin Landa) Date: Wed, 15 Apr 2015 13:58:12 +0200 Subject: [GRASS-dev] open suse update info Message-ID: Hi, [1] says """ This GRASS version 7 is a development version for testing and is not meant to be used for daily work. """ which should be updated I would say :-) Thanks, Martin [1] http://software.opensuse.org/package/grass7 -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From neteler at osgeo.org Wed Apr 15 05:17:55 2015 From: neteler at osgeo.org (Markus Neteler) Date: Wed, 15 Apr 2015 14:17:55 +0200 Subject: [GRASS-dev] open suse update info In-Reply-To: References: Message-ID: Hi Angelos, Otto, On Wed, Apr 15, 2015 at 1:58 PM, Martin Landa wrote: > Hi, > > [1] says > > """ > This GRASS version 7 is a development version for testing and is not > meant to be used for daily work. > """ > > which should be updated I would say :-) Thanks, Martin > > [1] http://software.opensuse.org/package/grass7 would you be able to update the entry for us? thanks Markus From amitabh.tiwari27 at gmail.com Wed Apr 15 06:19:52 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Wed, 15 Apr 2015 18:49:52 +0530 Subject: [GRASS-dev] Feedback regarding RSI image mining Feature Message-ID: hello devs, It has been a couple of weeks since I discussed the proposal with you all.Can you provide some feedback about the feature that I'am trying to implement for GRASS-GIS. I can understand that you all would be very busy with your professional work in this part of the year but if you could take some time to help me out,it would be great. In seek of quick reply. Regards, -Amitabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Wed Apr 15 11:50:38 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 15 Apr 2015 14:50:38 -0400 Subject: [GRASS-dev] Rare t.rast.to.vect and t.rast.contour failures Message-ID: Hi, apparently t.rast.to.vect and t.rast.contour tests fail time to time. t.rast.to.vect failed on March 26 (r64922): http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-03-26-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.to.vect/test_to_vect/index.html and test's stdout looked also quite unsettled: http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-03-26-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.to.vect/test_to_vect/stdout.html http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-15-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.to.vect/test_to_vect/stdout.html Similarly, on April 14 (r65052) t.rast.contour failed: http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-14-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.contour/test_convert/index.html Stdout contains some errors regardless of the success state which might be all right (depends on what is tested): http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-14-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.contour/test_convert/stdout.html http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-15-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.contour/test_convert/stdout.html Vaclav -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Wed Apr 15 12:00:54 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 15 Apr 2015 15:00:54 -0400 Subject: [GRASS-dev] [GRASS-SVN] r65057 - in grass/trunk/db: db.login drivers/mysql drivers/postgres In-Reply-To: <20150415071454.2D820390131@trac.osgeo.org> References: <20150415071454.2D820390131@trac.osgeo.org> Message-ID: Hi Martin, On Wed, Apr 15, 2015 at 3:14 AM, wrote: > Author: martinl > Date: 2015-04-15 00:14:53 -0700 (Wed, 15 Apr 2015) > New Revision: 65057 > > Modified: > grass/trunk/db/db.login/db.login.html > grass/trunk/db/db.login/main.c > grass/trunk/db/drivers/mysql/db.c > grass/trunk/db/drivers/postgres/db.c > grass/trunk/db/drivers/postgres/listdb.c > Log: > db.login + pg & mysql driver: support hostname and port > > this looks awesome. I guess this will help with issue #2626 I encountered recently. BTW, do you have any plans to make it easily testable using Docker [2, 3]? Thanks, Vaclav [1] http://trac.osgeo.org/grass/ticket/2626 [2] http://courses.neteler.org/fun-docker-grass-gis-software/ [3] https://github.com/wenzeslaus/grass-gis-docker -------------- next part -------------- An HTML attachment was scrubbed... URL: From landa.martin at gmail.com Wed Apr 15 12:06:36 2015 From: landa.martin at gmail.com (Martin Landa) Date: Wed, 15 Apr 2015 21:06:36 +0200 Subject: [GRASS-dev] [GRASS-SVN] r65057 - in grass/trunk/db: db.login drivers/mysql drivers/postgres In-Reply-To: References: <20150415071454.2D820390131@trac.osgeo.org> Message-ID: Hi, 2015-04-15 21:00 GMT+02:00 Vaclav Petras : > this looks awesome. I guess this will help with issue #2626 I encountered > recently. yes, it's a goal. Now it should work with db.login (host/port). Other modules like v.out.ogr I am planning to test/update later (I hope during this weekend). > BTW, do you have any plans to make it easily testable using Docker [2, 3]? Hopefully will have time for that too. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From trac at osgeo.org Wed Apr 15 12:07:43 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 15 Apr 2015 19:07:43 -0000 Subject: [GRASS-dev] [GRASS GIS] #2626: v.out.ogr does not suggest db.connect and db.login when not set In-Reply-To: <044.c59b2f680c09064736bb9bedd32982c1@osgeo.org> References: <044.c59b2f680c09064736bb9bedd32982c1@osgeo.org> Message-ID: <053.aa1a3bceb0960b22ad1272557c34e30b@osgeo.org> #2626: v.out.ogr does not suggest db.connect and db.login when not set -------------------------------------------+-------------------------------- Reporter: wenzeslaus | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 7.1.0 Component: Vector | Version: svn-trunk Keywords: PostgreSQL, postgres, PostGIS | Platform: Linux Cpu: Unspecified | -------------------------------------------+-------------------------------- Changes (by martinl): * cc: grass-dev@? (added) * owner: grass-dev@? => martinl * status: new => assigned -- Ticket URL: GRASS GIS From Stefan.Blumentrath at nina.no Wed Apr 15 15:34:28 2015 From: Stefan.Blumentrath at nina.no (Blumentrath, Stefan) Date: Wed, 15 Apr 2015 22:34:28 +0000 Subject: [GRASS-dev] GRASS 7: r.stream.extract fails to read big input maps Message-ID: Dear all, I tried to extract a river network from a huge DEM: rows: 180752 cols: 141312 cells: 25542426624 r.watershed (in an older revision of GRASS 7) had no problem with the DEM and created raster streams very nicely. However, I could not convert them to vector because r.to.vect complained the streams weren't thinned properly. Since I would like to continue with the other r.streams.* addons anyway, I tried running r.stream.extract. On the entire DEM it failed with the error message below: (Mon Apr 13 23:21:30 2015) r.stream.extract --verbose elevation=dem_10m_nosefi_float at PERMANENT accumulation=dem_10m_nosefi_float_accum at Hydrologi threshold=1500 stream_length=5 memory=50000 stream_raster=dem_10m_nosefi_float_streams_ids stream_vector=dem_10m_nosefi_float_streams_ids 4.23% of data are kept in memory Will need up to 1285.49 GB (1316340 MB) of disk space Creating temporary files... Loading input raster maps... ERROR: Unable to load input raster map(s) (Wed Apr 15 12:44:30 2015) Command finished (2243 min 0 sec) >From the error message (Unable to load input raster map(s)), I have no idea where I could start searching for the problem... On a smaller catchment (with all in RAM calculation) r.stream.extract works fine... Any ideas how to fix this? Running r.stream.extract per catchment (delineated earlier with r.watershed) would be a possible workaround... Cheers Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitabh.tiwari27 at gmail.com Thu Apr 16 04:40:24 2015 From: amitabh.tiwari27 at gmail.com (Amitabh) Date: Thu, 16 Apr 2015 17:10:24 +0530 Subject: [GRASS-dev] GSoC Proposal-2015's Documentation Message-ID: Hello everyone, The document has the following: -Github link for the codes implemented. -Youtube link for the demonstration of working of codes. -The detailed timeline representation of the work done till now and how do i think of proceeding further. -The documentation of phase-1. In seek of feedbacks. Regards, Amitabh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: timeline.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 448804 bytes Desc: not available URL: From trac at osgeo.org Thu Apr 16 16:04:24 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 16 Apr 2015 23:04:24 -0000 Subject: [GRASS-dev] [GRASS GIS] #2653: GRASS 6.4.3 no file chooser popup for Add raster/vector map layer Message-ID: <042.d57291c7e1f6fa78d91eb1727ab2aa53@osgeo.org> #2653: GRASS 6.4.3 no file chooser popup for Add raster/vector map layer ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.1.0 Component: wxGUI | Version: 6.4.3 Keywords: | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- The current OSGeo4W 64-bit windows distribution installs GRASS 6.4.3 (later versions not offered). However, after a clean instillation of this I can not get data to display. There is no file chooser popup generated as a result of either the "Add raster map layer" or the "Add vector map layer" buttons in the layer manager. In addition, those layers that do show in the layer manager, as a result of importing from an external format, do not display in the Map display. If I install from the 32-bit OSGeo4W distribution, I only get a command line version at 6.4.3, but the 6.4.4 gui version works as expected in regard to the above issue. -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 16 20:02:47 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 17 Apr 2015 03:02:47 -0000 Subject: [GRASS-dev] [GRASS GIS] #2654: r.thin crashes Message-ID: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> #2654: r.thin crashes ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.thin | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- r.thin crashes (Windows message that GRASS 7 has stopped working). The input was first imported from the attached Erdas Imagine file into a new location (EPSG:2193), then thinned using the following commands; r.in.gdal input=D:\temp_work\temukaSub_rasterEdges.img output=rasterEdges --overwrite -e r.thin --overwrite --quiet input=rasterEdges output=thinnedRaster iterations=200 If the If the extent is not set using -e on the import, then it fails with "Unable to find bounding box for lines" but doesn't crash. I have tried the same on Linux machine and in that case the "crash" has a message: "Error writing temporary file". It has identical to above if the extent has not been defined (earlier versions of GRASS seemed to handle this). -- Ticket URL: GRASS GIS From trac at osgeo.org Fri Apr 17 00:49:25 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 17 Apr 2015 07:49:25 -0000 Subject: [GRASS-dev] [GRASS GIS] #2654: r.thin crashes In-Reply-To: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> References: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> Message-ID: <051.42112762c195ac1b0902d6615a8e0757@osgeo.org> #2654: r.thin crashes ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.thin | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by neteler): Please post here also the output of g.region -p Additionally, is there enough free space on the disk? -- Ticket URL: GRASS GIS From trac at osgeo.org Fri Apr 17 01:24:08 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 17 Apr 2015 08:24:08 -0000 Subject: [GRASS-dev] [GRASS GIS] #2654: r.thin crashes In-Reply-To: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> References: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> Message-ID: <051.864f4c194cc1f3b143ec51269037d9bd@osgeo.org> #2654: r.thin crashes ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.thin | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by marisn): I am somehow unable to reproduce described "crash". If it is a real crash not just a stop with error message, please, run r.thin from gdb and afterwards also under valgrind and provide obtained backtraces. Be ware - there was a serious flaw in documentation - r.thin is thinning non-null cells instead of non-zero cells, as documentation states. It is necessary to run r.null setnull=0 on your imported data otherwise thinning is useless. -- Ticket URL: GRASS GIS From trac at osgeo.org Fri Apr 17 02:16:19 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 17 Apr 2015 09:16:19 -0000 Subject: [GRASS-dev] [GRASS GIS] #2655: update t.connect to use db.login host= port= Message-ID: <041.1e3eb1014b0a97fe7d05d4478decfd3a@osgeo.org> #2655: update t.connect to use db.login host= port= ---------------------------+------------------------------------------------ Reporter: martinl | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Temporal | Version: svn-trunk Keywords: t.connect, pg | Platform: Unspecified Cpu: Unspecified | ---------------------------+------------------------------------------------ `t.connect` should be updated to use `db.login` for PostgreSQL host and port settings (introduced in r65057), see (1) (1) http://grass.osgeo.org/grass70/manuals/t.connect.html#postgresql -- Ticket URL: GRASS GIS From hellik at web.de Fri Apr 17 12:02:47 2015 From: hellik at web.de (Helmut Kudrnovsky) Date: Fri, 17 Apr 2015 12:02:47 -0700 (PDT) Subject: [GRASS-dev] GRASS GIS 7 Addons Manual pages - some mess up in short description Message-ID: <1429297367562-5201877.post@n6.nabble.com> hi, looking at http://grass.osgeo.org/grass70/manuals/addons/ there seems to be some mess up in short descriptions: [...] r.stream.basins: Calculates surface roughness in a moving-window, as the orientation of vectors normal to surface planes. r.stream.channel: Generates a smooth approximation of the input raster and a discontinuity map. r.stream.distance: Creates shades from various directions and combines then into RGB composition. r.stream.order: A model for shallow landslide susceptibility. r.stream.segment: Computes Sky-View Factor visualization technique [...] v.in.geopaparazzi: Computes the best-fitting ellipse for given vector data. v.in.gns: Links all OGR layers available in given OGR datasource. v.in.gps: segment points along a vector line with fixed distances v.in.ply: Lithospheric flexure: gridded deflections from scattered point loads v.in.proj: Calculates DEM derived characteristics of habitats. v.in.wfs2: Creates metadata based on ISO standard for specified vector map. v.isochrones: Imports data from Geopaparazzi database. ----- best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GRASS-GIS-7-Addons-Manual-pages-some-mess-up-in-short-description-tp5201877.html Sent from the Grass - Dev mailing list archive at Nabble.com. From trac at osgeo.org Sat Apr 18 07:42:18 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 18 Apr 2015 14:42:18 -0000 Subject: [GRASS-dev] [GRASS GIS] #2656: GRASS freezes for 5-10 mins before eventually showing attribute table Message-ID: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> #2656: GRASS freezes for 5-10 mins before eventually showing attribute table -----------------------------------------+---------------------------------- Reporter: richardc | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Vector | Version: svn-releasebranch70 Keywords: attribute table, postgresql | Platform: Linux Cpu: x86-64 | -----------------------------------------+---------------------------------- On attempting to display a vector attribute table in the Layer Manager, GRASS entirely freezes for about 5-10 mins, displaying the message - Please wait loading attribute data... - and then the attribute table is eventually displayed. I'm not sure if related to postgresql which I'm using instead of sqlite; sqlite tables are shown without trouble. I'm not sure if a bug, or how to resolve? Thanks, Richard {{{ Database: postgresql-9.3 Database size: 1542 MB / 53580 tables The attribute table is small: 1 row/10 columns db.test gives the following, which appears functional: db.test test=test1 Using DB driver: pg EXECUTE: OK EXECUTE: OK EXECUTE: OK EXECUTE: OK RESULT: OK EXECUTE: OK RESULT: OK EXECUTE: OK EXECUTE: OK EXECUTE: OK EXECUTE: OK ERROR: RESULT: ******** ERROR ******** 2d1 < 3|0|_\\'_| 3a3 > 3|0|_\'_| CREATE TABLE grass_test1 (i1 INTEGER, d1 DOUBLE PRECISION, c1 VARCHAR(20)) INSERT INTO grass_test1 VALUES ( 1, 123.456, 'abcd' ) INSERT INTO grass_test1 VALUES ( 2, null, 'xxx' ) SELECT * FROM grass_test1 SELECT c1 FROM grass_test1 WHERE d1 < 500 / 2 AND i1 <> 2 AND c1 LIKE '%bc%' INSERT INTO grass_test1 VALUES ( 3, 0.0, '_\''_' ) ALTER TABLE grass_test1 ADD COLUMN i2 INTEGER UPDATE grass_test1 SET d1 = 18.6, i2 = 987 WHERE i1 = 2 SELECT * FROM grass_test1 DROP TABLE grass_test1 EXECUTE: OK (Sat Apr 18 21:17:56 2015) Command finished (0 sec) My system: GRASS version: 7.0.1svn GRASS SVN Revision: 65041 Build Date: 2015-04-10 Build Platform: x86_64-unknown-linux-gnu GDAL/OGR: 1.11.2 PROJ.4: 4.9.0 GEOS: 3.4.2 SQLite: 3.8.2 Python: 2.7.6 wxPython: 2.8.12.1 Platform: Linux-3.13.0-37-generic-x86_64-with-LinuxMint-17.1-rebecca }}} -- Ticket URL: GRASS GIS From ychemin at gmail.com Sat Apr 18 14:26:25 2015 From: ychemin at gmail.com (Yann Chemin) Date: Sat, 18 Apr 2015 23:26:25 +0200 Subject: [GRASS-dev] Mac Compilation issue (iconv) Message-ID: Hi, facing a little issue with iconv on Mac. Anybody experienced this before? YMP:/lib/driver yann$ make cc -dynamiclib -compatibility_version 7.1 -current_version 7.1 -install_name /Applications/GRASS-7.1.app/Contents/MacOS/lib/libgrass_driver.7.1.svn.dylib -o /Users/yann/dev/grass_yann/dist.x86_64-apple-darwin14.3.0/lib/libgrass_driver.7.1.svn.dylib -L/Users/yann/dev/grass_yann/dist.x86_64-apple-darwin14.3.0/lib -L/Users/yann/dev/grass_yann/dist.x86_64-apple-darwin14.3.0/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -L/sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin14.1.0/4.9.2 OBJ.x86_64-apple-darwin14.3.0/font2.o OBJ.x86_64-apple-darwin14.3.0/set_window.o OBJ.x86_64-apple-darwin14.3.0/raster.o OBJ.x86_64-apple-darwin14.3.0/text_size.o OBJ.x86_64-apple-darwin14.3.0/parse_ftcap.o OBJ.x86_64-apple-darwin14.3.0/color.o OBJ.x86_64-apple-darwin14.3.0/text2.o OBJ.x86_64-apple-darwin14.3.0/font.o OBJ.x86_64-apple-darwin14.3.0/erase.o OBJ.x86_64-apple-darwin14.3.0/font_freetype.o OBJ.x86_64-apple-darwin14.3.0/line_width.o OBJ.x86_64-apple-darwin14.3.0/path.o OBJ.x86_64-apple-darwin14.3.0/text.o OBJ.x86_64-apple-darwin14.3.0/draw.o OBJ.x86_64-apple-darwin14.3.0/box.o OBJ.x86_64-apple-darwin14.3.0/graph.o OBJ.x86_64-apple-darwin14.3.0/init.o OBJ.x86_64-apple-darwin14.3.0/move.o OBJ.x86_64-apple-darwin14.3.0/get_t_box.o OBJ.x86_64-apple-darwin14.3.0/text3.o -lgrass_gis.7.1.svn -L/sw/lib -lfreetype -liconv Undefined symbols for architecture x86_64: "_iconv", referenced from: _draw_main in text3.o "_iconv_close", referenced from: _draw_main in text3.o "_iconv_open", referenced from: _draw_main in text3.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status ../../include/Make/Shlib.make:10: recipe for target '/Users/yann/dev/grass_yann/dist.x86_64-apple-darwin14.3.0/lib/libgrass_driver.7.1.svn.dylib' failed make: *** [/Users/yann/dev/grass_yann/dist.x86_64-apple-darwin14.3.0/lib/libgrass_driver.7.1.svn.dylib] Error 1 From trac at osgeo.org Sat Apr 18 21:53:02 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 19 Apr 2015 04:53:02 -0000 Subject: [GRASS-dev] [GRASS GIS] #2656: GRASS freezes for 5-10 mins before eventually showing attribute table In-Reply-To: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> References: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> Message-ID: <051.851ef60438cfcc84530bb1321b9b19f1@osgeo.org> #2656: GRASS freezes for 5-10 mins before eventually showing attribute table -----------------------------------------+---------------------------------- Reporter: richardc | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Vector | Version: svn-releasebranch70 Keywords: attribute table, postgresql | Platform: Linux Cpu: x86-64 | -----------------------------------------+---------------------------------- Comment(by richardc): My comment about the sqlite db is wrong - I have the same issue in trying to display a sqlite vector attribute table with the entire GRASS application freezing. -- Ticket URL: GRASS GIS From mlennert at club.worldonline.be Sat Apr 18 22:52:06 2015 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sun, 19 Apr 2015 07:52:06 +0200 Subject: [GRASS-dev] port of v.points.cog to python In-Reply-To: <20150301160115.GA25881@free.fr> References: <20150301160115.GA25881@free.fr> Message-ID: <55334286.4030605@club.worldonline.be> On 01/03/15 17:01, Patrice Dumas wrote: > Hello, > > Here is a rewrite of the v.points.cog module in python. I tried > translating code only, keeping the code organization, variables names as it > was previously to help those who would want to review the differences > with the shell script. I also did the few changes required for changes > in grass7, but there weren't that much since python function already > abstract some commands. > > I did a svn copy of the grass6 module before doing the modifications. > > I cannot (and don't want to...) claim any copyright on a code translation. > > I didn't test thoroughly, but since it is code translation, I don't expect > big surprises. Coming back to this: MarkusM, how difficult would it be to integrate that functionality directly into v.centerpoint, i.e. something like this: v.centerpoint ... use=attr column= and v.centerpoint ... use=cat which would create one centerpoint for each collection of features with the same value for attr or cat ? One use case I'm confronted with right now is that I use v.cluster and want to find the cluster centers to then get statistics about distance to cluster centers within each cluster. Currently, I have to loop through the cluster and run v.centerpoint on each. Moritz From trac at osgeo.org Sat Apr 18 23:14:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 19 Apr 2015 06:14:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2656: GRASS freezes for 5-10 mins before eventually showing attribute table In-Reply-To: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> References: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> Message-ID: <051.5f21af18682b57911a7394a573a87543@osgeo.org> #2656: GRASS freezes for 5-10 mins before eventually showing attribute table -----------------------------------------+---------------------------------- Reporter: richardc | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: Vector | Version: svn-releasebranch70 Keywords: attribute table, postgresql | Platform: Linux Cpu: x86-64 | -----------------------------------------+---------------------------------- Comment(by richardc): Replying to [comment:1 richardc]: > My comment about the sqlite db is wrong - I have the same issue in trying to display a sqlite vector attribute table with the entire GRASS application freezing. However, attribute data can be displayed within 1 second with v.db.select (with postgresql db): {{{ v.db.select map=bnd_cahpa_f1apr_05216_nc_remapped_nc_1 at cahpa05216psql cat|to_bas|sub_bas|maj_bas|sub_name|maj_name|sub_area|maj_area|legend|cap_average 1|-999|21014|5021|pran|Peninsula Malaysia|3732|311477|21|2.07500273518235e-05 (Sun Apr 19 13:10:47 2015) Command finished (0 sec) }}} Issue is related to right clicking on layer name in Layer Manager and selecting 'Show attribute data' -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 18 23:14:39 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 19 Apr 2015 06:14:39 -0000 Subject: [GRASS-dev] [GRASS GIS] #2656: GRASS freezes for 5-10 mins before eventually showing attribute table In-Reply-To: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> References: <042.1515784c8f32cc11226caed7dccde1ff@osgeo.org> Message-ID: <051.11e52b87f13a79f4966f3609207994a5@osgeo.org> #2656: GRASS freezes for 5-10 mins before eventually showing attribute table -----------------------------------------+---------------------------------- Reporter: richardc | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: wxGUI | Version: svn-releasebranch70 Keywords: attribute table, postgresql | Platform: Linux Cpu: x86-64 | -----------------------------------------+---------------------------------- Changes (by richardc): * component: Vector => wxGUI -- Ticket URL: GRASS GIS From landa.martin at gmail.com Sun Apr 19 01:22:09 2015 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 19 Apr 2015 10:22:09 +0200 Subject: [GRASS-dev] pygrass: ipdb dependency Message-ID: Hi, it's seems that pygrass depends on ipdb, see lib/python/pygrass/vector/geometry.py: import ipdb; ipdb.set_trace() on other places such line is commented out. Is such dependency really needed? Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From trac at osgeo.org Sun Apr 19 05:24:36 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 19 Apr 2015 12:24:36 -0000 Subject: [GRASS-dev] [GRASS GIS] #2657: pygrass: remove RasterNumpy references Message-ID: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> #2657: pygrass: remove RasterNumpy references ----------------------------------+----------------------------------------- Reporter: martinl | Owner: grass-dev@? Type: task | Status: new Priority: major | Milestone: 7.0.1 Component: Python | Version: unspecified Keywords: pygrass, RasterNumpy | Platform: Unspecified Cpu: Unspecified | ----------------------------------+----------------------------------------- PyGRASS documentation and benchmarks still contain reference to non- existing `RasterNumpy` class. {{{ docs/src/pygrass_raster.rst pygrass/tests/benchmark.py }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 19 05:26:10 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 19 Apr 2015 12:26:10 -0000 Subject: [GRASS-dev] [GRASS GIS] #2657: pygrass: remove RasterNumpy references In-Reply-To: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> References: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> Message-ID: <050.ac84926b55547b8596c4e704f3cb80bb@osgeo.org> #2657: pygrass: remove RasterNumpy references ----------------------------------+----------------------------------------- Reporter: martinl | Owner: grass-dev@? Type: task | Status: new Priority: major | Milestone: 7.0.1 Component: PyGRASS | Version: unspecified Keywords: pygrass, RasterNumpy | Platform: Unspecified Cpu: Unspecified | ----------------------------------+----------------------------------------- Changes (by martinl): * component: Python => PyGRASS -- Ticket URL: GRASS GIS From peter.zamb at gmail.com Sun Apr 19 06:26:57 2015 From: peter.zamb at gmail.com (Pietro) Date: Sun, 19 Apr 2015 15:26:57 +0200 Subject: [GRASS-dev] pygrass: ipdb dependency In-Reply-To: References: Message-ID: Hi Martin, On Sun, Apr 19, 2015 at 10:22 AM, Martin Landa wrote: > lib/python/pygrass/vector/geometry.py: import ipdb; ipdb.set_trace() > > on other places such line is commented out. Is such dependency really needed? no, it is just for debugging. In particular the one that is present on geometry.py is acalled only when an exception from the SQL is raised: {{{ try: cur = self.table.execute(sql.SELECT_WHERE.format(cols=key, tname=self.table.name, condition=self.cond)) except: import ipdb; ipdb.set_trace() }}} Because I was trying to catch a bug, therefore the ipdb is imported only if the sql execution fails, I can easily remove it. I don't think it is a big issue. Best regards Pietro From landa.martin at gmail.com Sun Apr 19 06:32:21 2015 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 19 Apr 2015 15:32:21 +0200 Subject: [GRASS-dev] pygrass: region do not align to raster Message-ID: Hi all, it's seems to me that Region.align() is not working in pygrass as expected. region = Region() print region.rows -> is 977 region.align(rast) print region.rows -> should be 11682, but prints 977 Or do I overlooked anything? Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From landa.martin at gmail.com Sun Apr 19 06:37:08 2015 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 19 Apr 2015 15:37:08 +0200 Subject: [GRASS-dev] pygrass: region do not align to raster In-Reply-To: References: Message-ID: 2015-04-19 15:32 GMT+02:00 Martin Landa : > region = Region() > print region.rows -> is 977 > region.align(rast) > print region.rows -> should be 11682, but prints 977 > > Or do I overlooked anything? Thanks, Martin ah, it's just align just to resolution, not bounds. My original question: is how to read raster using RasterRow() using raster's region not the current region? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From landa.martin at gmail.com Sun Apr 19 06:38:00 2015 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 19 Apr 2015 15:38:00 +0200 Subject: [GRASS-dev] pygrass: region do not align to raster In-Reply-To: References: Message-ID: 2015-04-19 15:37 GMT+02:00 Martin Landa : > ah, it's just align just to resolution, not bounds. My original but documentation claims: adjust region cells to cleanly align with this raster map Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From peter.zamb at gmail.com Sun Apr 19 06:40:46 2015 From: peter.zamb at gmail.com (Pietro) Date: Sun, 19 Apr 2015 15:40:46 +0200 Subject: [GRASS-dev] pygrass: region do not align to raster In-Reply-To: References: Message-ID: Hi Martin, On Sun, Apr 19, 2015 at 3:32 PM, Martin Landa wrote: > it's seems to me that Region.align() is not working in pygrass as expected. > > region = Region() > print region.rows -> is 977 > region.align(rast) > print region.rows -> should be 11682, but prints 977 You are right, all the methods: align and zoom are wrong, because their are calling the g.region module, that it is execute in an external process and therefore does not affect the current one, therefore they should be: - removed or - re-implemented to provide the same functionality remaining in the same process or - move the align and zoom functions from the g.region module to the library link them with ctypes and call them from the method. Pietro From landa.martin at gmail.com Sun Apr 19 06:45:14 2015 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 19 Apr 2015 15:45:14 +0200 Subject: [GRASS-dev] pygrass: region do not align to raster In-Reply-To: References: Message-ID: Hi, 2015-04-19 15:40 GMT+02:00 Pietro : > You are right, all the methods: align and zoom are wrong, because > their are calling the g.region module, that it is execute in an > external process and therefore does not affect the current one, yes, thanks for confirmation. Back to the original question, is there any other way how to read raster from it's region and not from the current computational region set by g.region? Thanks, Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From nik at nikosalexandris.net Sun Apr 19 09:53:20 2015 From: nik at nikosalexandris.net (Nikos Alexandris) Date: Sun, 19 Apr 2015 19:53:20 +0300 Subject: [GRASS-dev] Use of r.mapcalc vs i.vi inside a script Message-ID: <20150419165320.GB26054@tpx1c2g> Dear developers, this is a question related to performance, I think. Is it better to prefer r.mapcalc or use i.vi to derive the NDVI inside a python script? Thank you, Nikos From trac at osgeo.org Sun Apr 19 18:30:08 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 01:30:08 -0000 Subject: [GRASS-dev] [GRASS GIS] #2654: r.thin crashes In-Reply-To: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> References: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> Message-ID: <051.68823590a9554ac6da5fb12311dfacf2@osgeo.org> #2654: r.thin crashes ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.thin | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by pairmand): Thank you both for your help - I think it was actually multiple unrelated problems. If I create a new location/mapset then g.region -p produces; {{{ g.region -p projection: 99 (Transverse Mercator) zone: 0 datum: nzgd2k ellipsoid: grs80 north: 1 south: 0 west: 0 east: 1 nsres: 1 ewres: 1 rows: 1 cols: 1 cells: 1 (Mon Apr 20 11:50:24 2015) Command finished (0 sec) }}} If I then import the Imagine file with extend region and repeat I get; {{{ r.in.gdal input=D:\temp_work\temukaSub_rasterEdges.img output=temukaSub_rasterEdges -e WARNING: Datum not recognised by GRASS and no parameters found Raster map created. Region for the current mapset updated r.in.gdal complete. (Mon Apr 20 11:53:07 2015) Command finished (0 sec) (Mon Apr 20 11:53:20 2015) g.region -p projection: 99 (Transverse Mercator) zone: 0 datum: nzgd2k ellipsoid: grs80 north: 5117010 south: 0 west: 0 east: 1474010 nsres: 1 ewres: 1 rows: 5117010 cols: 1474010 cells: 7542523910100 (Mon Apr 20 11:53:20 2015) Command finished (0 sec) }}} That is, the map coordinates seem to be set to the north east corner but south, west, cols and rows are all incorrect. This appears to be a bug importing from the Imagine file using the gdal importer. If I try and thin at this point then the thin crashes - see screenshot. [[Image(http://trac.osgeo.org/grass/attachment/ticket/2654/GrassCrash.JPG)]] However, if I use g.region to correct the above I get a result that looks good; {{{ g.region raster=temukaSub_rasterEdges (Mon Apr 20 12:03:08 2015) Command finished (0 sec) (Mon Apr 20 12:03:22 2015) g.region -p projection: 99 (Transverse Mercator) zone: 0 datum: nzgd2k ellipsoid: grs80 north: 5117010 south: 5108000 west: 1463000 east: 1474010 nsres: 10 ewres: 10 rows: 901 cols: 1101 cells: 992001 (Mon Apr 20 12:03:22 2015) Command finished (0 sec) }}} At this point running r.thin still produces an error and only appears to have processed the middle section of the image. {{{ ... Thinning not completed, consider to increase 'iterations' parameter. Output map 901 rows X 1101 columns Window 901 rows X 1101 columns (Mon Apr 20 12:04:46 2015) Command finished (17 sec) }}} Setting 0 as null cells fixes that problem also; {{{ r.null map=temukaSub_rasterEdges setnull=0 (Mon Apr 20 12:06:49 2015) Command finished (0 sec) (Mon Apr 20 12:07:20 2015) r.thin --overwrite input=temukaSub_rasterEdges at canTest output=temukaThinned Raster map - 901 rows X 1101 columns Bounding box: l = 2, r = 1102, t = 2, b = 902 Pass number 1 Deleted 68577 pixels Pass number 2 Deleted 2270 pixels Pass number 3 Deleted 37 pixels Pass number 4 Deleted 0 pixels Thinning completed successfully. Output map 901 rows X 1101 columns Window 901 rows X 1101 columns (Mon Apr 20 12:07:21 2015) Command finished (0 sec) }}} So I'm now a happy camper - but suggest there is a bug in the raster importer, in that it doesn't set the extent correctly, and the documentation of r.thin definitely needs to clarify that it is working on nulls not zeros. Thanks again for your help. David -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 19 21:09:33 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 04:09:33 -0000 Subject: [GRASS-dev] [GRASS GIS] #2658: v.to.db compactness gives wrong results in feet location Message-ID: <042.d98ec8bec4bc26583690fbe9def9279a@osgeo.org> #2658: v.to.db compactness gives wrong results in feet location -----------------------------------------------+---------------------------- Reporter: annakrat | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 7.0.1 Component: LibGIS | Version: svn-releasebranch70 Keywords: v.to.db, units, area, compactness | Platform: All Cpu: Unspecified | -----------------------------------------------+---------------------------- I was looking in the source code of v.to.db to understand if computed area is in meters squared or location units (feet in my case). I realized area is converted to meters squared, however, perimeter seems to be in map units (feet). Therefore compactness is wrong when units are not meters (latlon is fine I guess). Setting feet as units doesn't influence compactness computation. Currently the library functions for computing area and perimeter don't behave consistently. -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 01:01:37 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 08:01:37 -0000 Subject: [GRASS-dev] [GRASS GIS] #2654: r.thin crashes In-Reply-To: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> References: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> Message-ID: <051.87403a8ed879cc69f75550f510bce9d7@osgeo.org> #2654: r.thin crashes ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.thin | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by mlennert): Replying to [comment:3 pairmand]: > Thank you both for your help - I think it was actually multiple unrelated problems. > If I create a new location/mapset then g.region -p produces; > > {{{ > g.region -p > projection: 99 (Transverse Mercator) > zone: 0 > datum: nzgd2k > ellipsoid: grs80 > north: 1 > south: 0 > west: 0 > east: 1 > nsres: 1 > ewres: 1 > rows: 1 > cols: 1 > cells: 1 > (Mon Apr 20 11:50:24 2015) Command finished (0 sec) > }}} > > If I then import the Imagine file with extend region and repeat I get; > > {{{ > r.in.gdal input=D:\temp_work\temukaSub_rasterEdges.img output=temukaSub_rasterEdges -e > WARNING: Datum not recognised by GRASS and no parameters found > Raster map created. > Region for the current mapset updated > r.in.gdal complete. > (Mon Apr 20 11:53:07 2015) Command finished (0 sec) > (Mon Apr 20 11:53:20 2015) > g.region -p > projection: 99 (Transverse Mercator) > zone: 0 > datum: nzgd2k > ellipsoid: grs80 > north: 5117010 > south: 0 > west: 0 > east: 1474010 > nsres: 1 > ewres: 1 > rows: 5117010 > cols: 1474010 > cells: 7542523910100 > (Mon Apr 20 11:53:20 2015) Command finished (0 sec) > }}} > > > That is, the map coordinates seem to be set to the north east corner but south, west, cols and rows are all incorrect. This appears to be a bug importing from the Imagine file using the gdal importer. The man page of r.in.gdal says about the '-e' flag: "Extend region extents based on new dataset". It does not say: Set the computational region to the extents of the imported map. So, the behaviour is conform to what it announces: your region is '''extended''' so that it also englobes the imported map. I think that r.thin should not crash if there are no null values, so this is a bug, but AFAICS there is no bug in r.in.gdal. Moritz -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 01:23:35 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 08:23:35 -0000 Subject: [GRASS-dev] [GRASS GIS] #2337: t.list hangs on newly created temporal DB In-Reply-To: <041.02a534f9676d714746db1a26688b2e93@osgeo.org> References: <041.02a534f9676d714746db1a26688b2e93@osgeo.org> Message-ID: <050.856ffc0456f92bd12c4e418f878738aa@osgeo.org> #2337: t.list hangs on newly created temporal DB -----------------------------------+---------------------------------------- Reporter: neteler | Owner: grass-dev@? Type: task | Status: new Priority: normal | Milestone: 7.0.1 Component: Temporal | Version: svn-releasebranch70 Keywords: t.list, t.create, NFS | Platform: Linux Cpu: Unspecified | -----------------------------------+---------------------------------------- Changes (by spareeth): * cc: spareeth (added) * type: defect => task Comment: Hi The solution is not yet backported into GRASS 7.0.1 Can we have it done? Thank you Sajid -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 03:12:16 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 10:12:16 -0000 Subject: [GRASS-dev] [GRASS GIS] #2659: replace function bug in t.rast.mapcalc.py Message-ID: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> #2659: replace function bug in t.rast.mapcalc.py ----------------------------+----------------------------------------------- Reporter: eosduero | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Python | Version: 7.0.0 Keywords: t.rast.mapcalc | Platform: Unspecified Cpu: x86-32 | ----------------------------+----------------------------------------------- There is a bug in the ''t.rast.mapcalc.py'' function. The problem occurs when we have 2 temporal datasets with similar names, for example: * map1 * ecmmap1 When we try: {{{ t.rast.mapcalc.py" --o input=map1,ecmmap1 expr="map1 - ecmmap1" out=sal1 basename=sal1 method=start }}} It cause an error. I think that the problem is in the line 217 (file ''etc\python\grass\temporal\mapcalc.py''): {{{ expr = expr.replace(id_list[j], map_matrix[j][i]) }}} The function can not replace correctly the raster dataset when they have equal substrings. Thanks and sorry for my english. -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 03:23:31 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 10:23:31 -0000 Subject: [GRASS-dev] [GRASS GIS] #2659: replace function bug in t.rast.mapcalc.py In-Reply-To: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> References: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> Message-ID: <051.10964474f17a8af6ed607e4714afc91c@osgeo.org> #2659: replace function bug in t.rast.mapcalc.py ----------------------------+----------------------------------------------- Reporter: eosduero | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Python | Version: 7.0.0 Keywords: t.rast.mapcalc | Platform: Unspecified Cpu: x86-32 | ----------------------------+----------------------------------------------- Comment(by eosduero): NOTE: In the example the ''basename'' of map1 and ecmmap1 ''datasets'' were created with the same name (map1 and ecmmap1). -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 03:29:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 10:29:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2654: r.thin crashes In-Reply-To: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> References: <042.abfb9cdf9103dbc793e17ee65e1b3d47@osgeo.org> Message-ID: <051.dd2b48665ebdcc9c1f48ab7c5fd68bf9@osgeo.org> #2654: r.thin crashes ----------------------+----------------------------------------------------- Reporter: pairmand | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.thin | Platform: MSWindows 7 Cpu: x86-64 | ----------------------+----------------------------------------------------- Comment(by marisn): Replying to [comment:4 mlennert]: > > I think that r.thin should not crash if there are no null values, so this is a bug, but AFAICS there is no bug in r.in.gdal. > > Moritz I have been unable to reproduce crash on my Linux machine so far. As far as I could understand, the crash is not rising from no lines to thin (lack of null values) but from running out of memory / disk space due to enormous computational region. I have updated documentation to match module behaviour in r65083 (0 vs null) and removed use of unused error_prefix in r65101 The error message "Error writing temporary file" indicates running out of disk space. It is not a crash. Unless someone manages to reproduce crash on Linux (and provide output of gdb and valgrind!), I would tend to close this issue as caused by too large computational region. -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 03:50:59 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 10:50:59 -0000 Subject: [GRASS-dev] [GRASS GIS] #2659: replace function bug in t.rast.mapcalc.py In-Reply-To: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> References: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> Message-ID: <051.64858a1af515d3970ffd719de47ee363@osgeo.org> #2659: replace function bug in t.rast.mapcalc.py ----------------------------+----------------------------------------------- Reporter: eosduero | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Python | Version: 7.0.0 Keywords: t.rast.mapcalc | Platform: Unspecified Cpu: x86-32 | ----------------------------+----------------------------------------------- Comment(by eosduero): A possible solution: {{{ # current time step for j in range(len(map_matrix)): if map_matrix[j][i] is None: valid_maps = False break # Substitute the dataset name with the map name expr = expr.replace(id_list[j], "aux__%00002d__" % j) # EOS for j in range(len(map_matrix)): if map_matrix[j][i] is None: valid_maps = False break # Substitute the dataset name with the map name expr = expr.replace("aux__%00002d__" % j, map_matrix[j][i]) }}} -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 04:40:35 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 11:40:35 -0000 Subject: [GRASS-dev] [GRASS GIS] #2649: r.to.vect diagonals defect fixed In-Reply-To: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> References: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> Message-ID: <052.24bd4b67bc734988b80dc43691100ade@osgeo.org> #2649: r.to.vect diagonals defect fixed -----------------------+---------------------------------------------------- Reporter: byronbest | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: unspecified Keywords: r.to.vect | Platform: All Cpu: x86-64 | -----------------------+---------------------------------------------------- Changes (by neteler): * keywords: => r.to.vect Comment: Can you please post a test case/screenshot to better understand the problem? -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 05:43:39 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 12:43:39 -0000 Subject: [GRASS-dev] [GRASS GIS] #2337: t.list hangs on newly created temporal DB In-Reply-To: <041.02a534f9676d714746db1a26688b2e93@osgeo.org> References: <041.02a534f9676d714746db1a26688b2e93@osgeo.org> Message-ID: <050.8a25fb94c81a0371082e04d5c6525b2e@osgeo.org> #2337: t.list hangs on newly created temporal DB -----------------------+---------------------------------------------------- Reporter: neteler | Owner: grass-dev@? Type: task | Status: closed Priority: normal | Milestone: 7.0.1 Component: Temporal | Version: svn-releasebranch70 Resolution: fixed | Keywords: t.list, t.create, NFS Platform: Linux | Cpu: Unspecified -----------------------+---------------------------------------------------- Changes (by neteler): * status: new => closed * resolution: => fixed Comment: Replying to [comment:8 spareeth]: > The solution is not yet backported into GRASS 7.0.1 Done in r65103 through backport of r64470. Closing ticket. -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 20 06:55:23 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 13:55:23 -0000 Subject: [GRASS-dev] [GRASS GIS] #2659: replace function bug in t.rast.mapcalc.py In-Reply-To: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> References: <042.1a0d1e2b55d3c475b5ea422e2e071561@osgeo.org> Message-ID: <051.68c3285e0837a069adda2cc6344597d6@osgeo.org> #2659: replace function bug in t.rast.mapcalc.py ----------------------------+----------------------------------------------- Reporter: eosduero | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Python | Version: 7.0.0 Keywords: t.rast.mapcalc | Platform: Unspecified Cpu: x86-32 | ----------------------------+----------------------------------------------- Comment(by eosduero): Other better posibility: {{{ ............... from grass.exceptions import CalledModuleError import re ############################################################################ def multiple_replace(string, rep_dict): pattern = re.compile("|".join([re.escape(k) for k in rep_dict.keys()]), re.M) return pattern.sub(lambda x: rep_dict[x.group(0)], string) ................... # Replace all dataset names with their map names of the # current time step plants = {} for j in range(len(map_matrix)): if map_matrix[j][i] is None: valid_maps = False break # Substitute the dataset name with the map name #expr = expr.replace(id_list[j], map_matrix[j][i]) plants[id_list[j]] = map_matrix[j][i] #msgr.message() expr = multiple_replace(expr, plants) }}} -- Ticket URL: GRASS GIS From neteler at osgeo.org Mon Apr 20 07:02:33 2015 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 20 Apr 2015 16:02:33 +0200 Subject: [GRASS-dev] GRASS GIS 7 Addons Manual pages - some mess up in short description In-Reply-To: <1429297367562-5201877.post@n6.nabble.com> References: <1429297367562-5201877.post@n6.nabble.com> Message-ID: On Fri, Apr 17, 2015 at 9:02 PM, Helmut Kudrnovsky wrote: > hi, > > looking at http://grass.osgeo.org/grass70/manuals/addons/ there seems to be > some mess up in short descriptions: The incomplete manual pages of r.green*.html are breaking the script which creates the overview. I spent already lot of time to work around that but have no more time for that. Markus PS: Also addon pages must follow https://trac.osgeo.org/grass/wiki/Submitting/Docs From trac at osgeo.org Mon Apr 20 07:17:07 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 20 Apr 2015 14:17:07 -0000 Subject: [GRASS-dev] [GRASS GIS] #2649: r.to.vect diagonals defect fixed In-Reply-To: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> References: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> Message-ID: <052.59df377cafb00d5c37037a5efc6bcd9a@osgeo.org> #2649: r.to.vect diagonals defect fixed -----------------------+---------------------------------------------------- Reporter: byronbest | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: unspecified Keywords: r.to.vect | Platform: All Cpu: x86-64 | -----------------------+---------------------------------------------------- Comment(by byronbest): Consider the result of r.drain, which is an already-thinned line of pixel centres, obviously in "runs" of x,y moving +/- 1 in x and/or y. We'd like for the runs be "collapsed" into only the corners where the direction changes. Further, we'd like that running the stream on another grid respect that we also need the corners where the color or value on the resulting line changes. The segments will be given the color of the pixel under the second of every pair. r.to.vect already handles these runs when they are straight in the x or y, but not in diagonals where both x and y change. The attached before/after screen shots show where this has become a visible defect. -- Ticket URL: GRASS GIS From wenzeslaus at gmail.com Mon Apr 20 07:26:08 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Mon, 20 Apr 2015 10:26:08 -0400 Subject: [GRASS-dev] GRASS GIS 7 Addons Manual pages - some mess up in short description In-Reply-To: References: <1429297367562-5201877.post@n6.nabble.com> Message-ID: On Mon, Apr 20, 2015 at 10:02 AM, Markus Neteler wrote: > > On Fri, Apr 17, 2015 at 9:02 PM, Helmut Kudrnovsky wrote: > > hi, > > > > looking at http://grass.osgeo.org/grass70/manuals/addons/ there seems to be > > some mess up in short descriptions: > > The incomplete manual pages of r.green*.html are breaking the script > which creates the overview. > I spent already lot of time to work around that but have no more time for that. > > Markus > > PS: Also addon pages must follow > https://trac.osgeo.org/grass/wiki/Submitting/Docs Perhaps there could be script and page which would show the guilty modules. There are already pages about build of the module. Perhaps there is a way to extent it or clone it to check for (some) submitting rules. There is a script to do static source code analysis for Python code: https://svn.osgeo.org/grass/sandbox/wenzeslaus/grass_py_static_check.py http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#analyzing-quality-of-source-code > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Tue Apr 21 07:01:20 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 21 Apr 2015 14:01:20 -0000 Subject: [GRASS-dev] [GRASS GIS] #2621: r.random.cells should use NULL instead of 0 In-Reply-To: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> References: <040.0552c14d739bcd121990ee35a85b1082@osgeo.org> Message-ID: <049.a86cda12dbc8557df379edcdc753a4b3@osgeo.org> #2621: r.random.cells should use NULL instead of 0 --------------------------+------------------------------------------------- Reporter: marisn | Owner: grass-dev@? Type: defect | Status: closed Priority: normal | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Resolution: fixed | Keywords: r.random.cells Platform: Unspecified | Cpu: Unspecified --------------------------+------------------------------------------------- Changes (by neteler): * status: new => closed * resolution: => fixed Comment: Replying to [comment:5 marisn]: > I would say - fix documentation, add to GRASS 7.1 changes and close this issue. While I don't fully agree I have clarified the presence of 0 in r65117 (relbr7). Closing. -- Ticket URL: GRASS GIS From neteler at osgeo.org Tue Apr 21 07:07:23 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 21 Apr 2015 16:07:23 +0200 Subject: [GRASS-dev] Use of r.mapcalc vs i.vi inside a script In-Reply-To: <20150419165320.GB26054@tpx1c2g> References: <20150419165320.GB26054@tpx1c2g> Message-ID: Hi Nikos, On Sun, Apr 19, 2015 at 6:53 PM, Nikos Alexandris wrote: > Dear developers, > > this is a question related to performance, I think. Is it better to > prefer r.mapcalc or use i.vi to derive the NDVI inside a python > script? since there are many factors influencing it, you may have to benchmark it. Please report it in case. Markus From trac at osgeo.org Tue Apr 21 08:27:24 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 21 Apr 2015 15:27:24 -0000 Subject: [GRASS-dev] [GRASS GIS] #2649: r.to.vect diagonals defect fixed In-Reply-To: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> References: <043.50f8e62e4781ed66888d9f01bd052805@osgeo.org> Message-ID: <052.b97857203277e216f94fbbfb5e6107ff@osgeo.org> #2649: r.to.vect diagonals defect fixed -----------------------+---------------------------------------------------- Reporter: byronbest | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: unspecified Keywords: r.to.vect | Platform: All Cpu: x86-64 | -----------------------+---------------------------------------------------- Comment(by neteler): All the tiff attachments seem to be broken (I tried two browsers), please use PNG format for screenshots. -- Ticket URL: GRASS GIS From neteler at osgeo.org Tue Apr 21 08:29:16 2015 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 21 Apr 2015 17:29:16 +0200 Subject: [GRASS-dev] GRASS GIS 7 Addons Manual pages - some mess up in short description In-Reply-To: References: <1429297367562-5201877.post@n6.nabble.com> Message-ID: On Mon, Apr 20, 2015 at 4:02 PM, Markus Neteler wrote: > On Fri, Apr 17, 2015 at 9:02 PM, Helmut Kudrnovsky wrote: >> looking at http://grass.osgeo.org/grass70/manuals/addons/ there seems to be >> some mess up in short descriptions: More manual pages got fixed and the above Addon index is ok again. Markus From matteo.marcantonio at fmach.it Tue Apr 21 12:40:56 2015 From: matteo.marcantonio at fmach.it (matmar) Date: Tue, 21 Apr 2015 12:40:56 -0700 (PDT) Subject: [GRASS-dev] GRASS command for raster and vector size Message-ID: <1429645256660-5202348.post@n6.nabble.com> Hi list, In the last few days I have been dealing with reduced amount of disk space due to map algebra operations in GRASS, then I was quite interested to know the size of GRASS objects in a easy way. I solved the problem with /ls -lh/ but I was wondering if a GRASS module (or a flag in an existing module) that prints the actual size of GRASS objects (raster, vector, temporal databases, etc) may be useful for GRASS users. I was thinking something like: *g.size type=raster,vector -m or -g (human readable byte units like Mb or Gb)* What do you think? Anybody willing to implement it? Matteo -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GRASS-command-for-raster-and-vector-size-tp5202348.html Sent from the Grass - Dev mailing list archive at Nabble.com. From trac at osgeo.org Tue Apr 21 13:17:54 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 21 Apr 2015 20:17:54 -0000 Subject: [GRASS-dev] [GRASS GIS] #2660: r.external.out: support paths relative to the mapset, and variables Message-ID: <037.137ba4dafb2e86bc5ee8f18050d7c63a@osgeo.org> #2660: r.external.out: support paths relative to the mapset, and variables ----------------------------+----------------------------------------------- Reporter: sbl | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: svn-releasebranch70 Keywords: r.external.out | Platform: Unspecified Cpu: Unspecified | ----------------------------+----------------------------------------------- Currently, r.external.out uses absolute paths which may be incorrect if the database is accessed via a networked filesystem (or even a local filesystem if the mount point changes). If the directory given to r.external.out is relative (doesn't begin with a "/"), it's converted to an absolute path relative to the current mapset directory. Thereafter, any created maps will have the absolute path in their GDAL link (i.e. the cell_misc//gdal file). Thus, maps created with r.external.out can't be read if the database directory has "moved" relative to its location when the map was created. It would be helpful if paths relative to the mapset could be supported, and maybe additional options, e.g. the ability to use environment variables in paths Here is a test case in order to reproduce the issue: First I created a new and empty GRASS Location "test" on a network storage (NFS) from the Linux Server. This GRASS DB is mounted on LINUX (through mount.cifs) to `/home/stefan/R_raw_data/test'. On Windows the "Network drive" is mapped to " R:\Raw_data\test " Within this Location I crated a mapset "linux" (from the Linux Server) and a mapset "windows" from my Windows 7 workstation. 1st test case: Linux to Windows: On the Linux server, and in the "linux" mapset I did: {{{ r.external.out --verbose directory="/home/stefan/R_raw_data/test" extension=".tif" format="GTiff" g.region -p n=1 s=0 e=1 w=0 res=0.1 r.mapcalc expression="linux_map=1" }}} On my Win 7 box I did: d.rast map= linux_map @linux Here I got the following error message: {{{ Command 'd.rast map=linux_map at linux' failed Details: ERROR 4: `/home/stefan/R_raw_data/test/linux_map.tif' does not exist in the file system, and is not recognised as a supported dataset name. }}} Then I tried relative paths: On Linux: {{{ r.external.out --verbose directory="../../" extension=".tif" format="GTiff" r.mapcalc expression="linux_map=1" --o }}} Error message on Windows changes to: {{{ Command 'd.rast map=linux_map at linux' failed Details: ERROR 4: `/home/stefan/R_raw_data/test/newLocation/linux/../..//linux_map.tif' does not exist in the file system, and is not recognised as a supported dataset name. }}} 2nd test case: Windows to Linux: On my Windows box (and in the "windows" mapset) I did: {{{ r.external.out --verbose directory="R:\Raw_data\test" extension=".tif" format="GTiff" r.mapcalc expression=windows_map=1 }}} Which results in the following error message: {{{ ERROR: Unable to make mapset element R:\Raw_data\test (R:\Raw_data\test/newLocation/windows/R:\Raw_data\test): No such file or directory }}} Then I tried relative paths: {{{ r.external.out --verbose directory="../../" extension=.tif format=GTiff }}} The relative paths work for the Windows side. However, back on Linux I tried: d.rast map=windows_map at windows and got the following error message: {{{ Command 'd.rast map=windows_map at windows' failed Details: ERROR 4: `R:\Raw_data\test/newLocation/windows/../..//windows_map.tif' does not exist in the file system, and is not recognised as a supported dataset name. }}} -- Ticket URL: GRASS GIS From landa.martin at gmail.com Tue Apr 21 14:02:07 2015 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 21 Apr 2015 23:02:07 +0200 Subject: [GRASS-dev] GRASS GIS 7 Addons Manual pages - some mess up in short description In-Reply-To: References: <1429297367562-5201877.post@n6.nabble.com> Message-ID: 2015-04-21 17:29 GMT+02:00 Markus Neteler : > More manual pages got fixed and the above Addon index is ok again. thanks for fixing it! Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa From trac at osgeo.org Tue Apr 21 15:25:54 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 21 Apr 2015 22:25:54 -0000 Subject: [GRASS-dev] [GRASS GIS] #2657: pygrass: remove RasterNumpy references In-Reply-To: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> References: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> Message-ID: <050.7644054c3e133f9810ee77d6d7432e56@osgeo.org> #2657: pygrass: remove RasterNumpy references ----------------------------------+----------------------------------------- Reporter: martinl | Owner: grass-dev@? Type: task | Status: new Priority: major | Milestone: 7.0.1 Component: PyGRASS | Version: unspecified Keywords: pygrass, RasterNumpy | Platform: Unspecified Cpu: Unspecified | ----------------------------------+----------------------------------------- Comment(by lucadelu): Removed in trunk with r65119. Please check it and after we can backport it -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 21 23:39:36 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 22 Apr 2015 06:39:36 -0000 Subject: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE In-Reply-To: <041.93f699efbd403e30f50830a445d0865d@osgeo.org> References: <041.93f699efbd403e30f50830a445d0865d@osgeo.org> Message-ID: <050.239b71eb8c9c3f4878f6f71c1c95c9aa@osgeo.org> #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE -------------------------------------------+-------------------------------- Reporter: neteler | Owner: grass-dev@? Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0 Component: Raster | Version: svn-trunk Keywords: compression, r.compress, null | Platform: All Cpu: Unspecified | -------------------------------------------+-------------------------------- Changes (by neteler): * keywords: compression, r.compress => compression, r.compress, null * milestone: 8.0.0 => 7.1.0 Comment: back to this topic: Here on our system I found > 1.7TB of NULL files in a single location, all uncompressed. What about having a "null2" file which is compressed and with index. If present, fine, otherwise use the uncompressed well known null file format? For backward compatibility, r.null could extended to convert from compressed null2 to uncompressed null (similar to v.build for the new spatial index in G7). -- Ticket URL: GRASS GIS From carlos.grohmann at gmail.com Wed Apr 22 05:44:02 2015 From: carlos.grohmann at gmail.com (Carlos Grohmann) Date: Wed, 22 Apr 2015 09:44:02 -0300 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? Message-ID: Hi I just installed the latest pkg for GRASS 7 on OSX (nice splash screen BTW) and r.shaded.relief is now just r.relief Is it too much if ask why this change? To me, r.shaded.relief is so much better, it describes the module. r.relief might be confusing (is it to calculate some rellief-related parameter? local relief? other morphometric parameter?). best Carlos -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of S?o Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/0000-0001-5073-5572 ________________ Can't stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Wed Apr 22 06:36:14 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 22 Apr 2015 13:36:14 -0000 Subject: [GRASS-dev] [GRASS GIS] #2657: pygrass: remove RasterNumpy references In-Reply-To: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> References: <041.afa2aadd97d0ae76740c7f64563b9edd@osgeo.org> Message-ID: <050.6936eb75778e1e017b03887bdf8001b4@osgeo.org> #2657: pygrass: remove RasterNumpy references ----------------------------------+----------------------------------------- Reporter: martinl | Owner: grass-dev@? Type: task | Status: new Priority: major | Milestone: 7.0.1 Component: PyGRASS | Version: unspecified Keywords: pygrass, RasterNumpy | Platform: Unspecified Cpu: Unspecified | ----------------------------------+----------------------------------------- Comment(by martinl): Replying to [comment:2 lucadelu]: > Removed in trunk with r65119. Please check it and after we can backport it Thanks, would probably make sense also add note how to interfere with numpy arrays? -- Ticket URL: GRASS GIS From wenzeslaus at gmail.com Wed Apr 22 06:57:56 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 22 Apr 2015 09:57:56 -0400 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: Hi Carlos, On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann wrote: > > Hi > > I just installed the latest pkg for GRASS 7 on OSX (nice splash screen BTW) > and r.shaded.relief is now just r.relief > > Is it too much if ask why this change? To me, r.shaded.relief is so much better, it describes the module. I did the rename after discussion with Michael Barton and Markus Neteler. We've tried to consider different names for several modules and picked the ones which seemed less confusing. See the discussion: http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html > > r.relief might be confusing (is it to calculate some rellief-related parameter? I'm afraid that in case of these modules, basically anything can be confusing. Let us know what do you think after reading the discussion, so we have some more feedback. > local relief? other morphometric parameter?). BTW, there is r.local.relief in addons. Vaclav > > > best > > Carlos > > > > -- > Prof. Carlos Henrique Grohmann > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > - Digital Terrain Analysis | GIS | Remote Sensing - > > http://carlosgrohmann.com > http://orcid.org/0000-0001-5073-5572 > ________________ > Can?t stop the signal. > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Wed Apr 22 12:59:21 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 22 Apr 2015 15:59:21 -0400 Subject: [GRASS-dev] raster.dll problem In-Reply-To: References: Message-ID: Unfortunately, raster.dll from ERDAS problem is still around. This happens in the Windows system command line on some computer when using v.in.proj using the dialog: C:\Users\john> ***ERROR NUMBER 2338 IN FUNCTION edll_InstanceOpenByClassName*** >>>DLL Open failed for C:/Program Files/Intergraph/ERDAS IMAGINE 2014/usr/lib/W in32Release/FileFilters/raster.dll<< ***ERROR NUMBER 162 IN FUNCTION edll_Open*** >>>Could not load DLL C:\Program Files\Intergraph\ERDAS IMAGINE 2014\usr\lib\Wi n32Release\FileFilters\raster.dll: The module was not found.<< ***ERROR NUMBER 2338 IN FUNCTION edll_InstanceOpenByClassName*** >>>DLL Open failed for C:/Program Files/Intergraph/ERDAS IMAGINE 2014/usr/lib/W in32Release/FileFilters/raster.dll<< ***ERROR NUMBER 162 IN FUNCTION edll_Open*** >>>Could not load DLL C:\Program Files\Intergraph\ERDAS IMAGINE 2014\usr\lib\Wi n32Release\FileFilters\raster.dll: The module was not found.<< Then GUI Command console reports a lot of errors when running g.gisenv -n. Previous tests using Dependency Walker revealed nothing. Some things suggested that it might be related to Browse button in wxPython but it's unclear. More investigation needed. Interestingly, the only things I was able to find about ERROR NUMBER ... IN FUNCTION edll_Open are: http://forums.esri.com/Thread.asp?c=93&f=38&t=132335&g=1 http://support.esri.com/ja/knowledgebase/techarticles/detail/16623 https://groups.yahoo.com/neo/groups/Arcview/conversations/messages/9840 I even don't know what to put to the WinGRASS errors page. Uninstall ERDAS? I was not able to check if this would help. http://grasswiki.osgeo.org/wiki/WinGRASS_errors On Sat, Jan 24, 2015 at 1:25 PM, Anna Petr??ov? wrote: > > > On Sat, Jan 24, 2015 at 12:56 PM, Markus Neteler > wrote: > >> On Sat, Jan 24, 2015 at 6:34 PM, Anna Petr??ov? >> wrote: >> > Hi, >> > >> > one student has problems running grass7 beta4. She keeps getting: >> > >> > Could not load DLL C:\Program Files\Intergraph\ERDAS Imagine >> > 2014\usr\lib\Win32Release\FileFilters\raster.dll: The module was not >> found. >> > >> > I couldn't find anything helpful. She gets this when running g.region, >> but I >> > am not sure if that's the only case. Any idea? >> >> She may try to disentangle the DLL dependencies (e.g. with "Dependency >> Walker" - only free as in free lunch, not software libero): >> http://www.dependencywalker.com. >> >> Perhaps then you see the issue. >> >> Markus >> > > > Thanks to you both for this suggestion, I will let you know if we find > anything useful. > > Anna > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Wed Apr 22 16:01:50 2015 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 23 Apr 2015 01:01:50 +0200 Subject: [GRASS-dev] Fwd: Re: [SAC] Upgrading Trac/SVN VM In-Reply-To: <20150422225224.GA3017@foehn.mgras.de> References: <20150417092825.GA31129@foehn.mgras.de> <20150422211554.GA2384@foehn.mgras.de> <20150422225224.GA3017@foehn.mgras.de> Message-ID: FYI ---------- Forwarded message ---------- From: "Martin Spott" Date: Apr 23, 2015 12:52 AM Subject: Re: [SAC] Upgrading Trac/SVN VM To: "System Administration Committee Discussion/OSGeo" Cc: On Wed, Apr 22, 2015 at 11:15:54PM +0200, Martin Spott wrote: > I know the Trac web page is currently unavailable - I'm in the process > of fixing it, The site should be running again - on Debian Squeeze (6.0). By accident (mistake) I also upgraded Trac from 0.11.7 on Python2.5 to 1.0.5 on Python2.6 and PostgreSQL from 8.3 to 8.4. I'm sure I broke something, but at least the Trac pages which are listed on: http://trac.osgeo.org/ .... are looking functional to me. Please report errors, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- _______________________________________________ Sac mailing list Sac at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/sac -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmitaso at ncsu.edu Wed Apr 22 20:06:46 2015 From: hmitaso at ncsu.edu (Helena Mitasova) Date: Wed, 22 Apr 2015 23:06:46 -0400 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: I agree with Carlos on this , I think r.shaded.relief was pretty clear what it was doing. As I learned recently, r.relief indeed can be confused with any of the numerous relief metrics. Helena On Wednesday, April 22, 2015, Vaclav Petras wrote: > Hi Carlos, > > On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann < > carlos.grohmann at gmail.com > > wrote: > > > > Hi > > > > I just installed the latest pkg for GRASS 7 on OSX (nice splash screen > BTW) > > and r.shaded.relief is now just r.relief > > > > Is it too much if ask why this change? To me, r.shaded.relief is so much > better, it describes the module. > > I did the rename after discussion with Michael Barton and Markus Neteler. > We've tried to consider different names for several modules and picked the > ones which seemed less confusing. See the discussion: > > http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html > > http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html > > > > > r.relief might be confusing (is it to calculate some rellief-related > parameter? > > I'm afraid that in case of these modules, basically anything can be > confusing. Let us know what do you think after reading the discussion, so > we have some more feedback. > > > local relief? other morphometric parameter?). > > BTW, there is r.local.relief in addons. > > Vaclav > > > > > > > best > > > > Carlos > > > > > > > > -- > > Prof. Carlos Henrique Grohmann > > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > > - Digital Terrain Analysis | GIS | Remote Sensing - > > > > http://carlosgrohmann.com > > http://orcid.org/0000-0001-5073-5572 > > ________________ > > Can?t stop the signal. > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev at lists.osgeo.org > > > http://lists.osgeo.org/mailman/listinfo/grass-dev > > -- Helena Mitasova Associate Professor Department of Marine, Earth and Atmospheric Sciences North Carolina State University 1125 Jordan Hall NCSU Box 8208 Raleigh, NC 27695-8208 http://www4.ncsu.edu/~hmitaso/ http://geospatial.ncsu.edu/ email: hmitaso at ncsu.edu ph: 919-513-1327 (no voicemail) fax 919 515-7802 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Thu Apr 23 03:09:18 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 23 Apr 2015 10:09:18 -0000 Subject: [GRASS-dev] [GRASS GIS] #2652: v.in.e00 In-Reply-To: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> References: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> Message-ID: <059.c7cdd76d909c541f771a253de224062a@osgeo.org> #2652: v.in.e00 -------------------------+------------------------- Reporter: templar112 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Vector | Version: 7.0.0 Resolution: | Keywords: CPU: x86-64 | Platform: MSWindows 8 -------------------------+------------------------- Comment (by neteler): Here are some E00 data: http://data.geocomm.com/catalog/US/61083/datalist.html -- Ticket URL: GRASS GIS From carlos.grohmann at gmail.com Thu Apr 23 05:41:42 2015 From: carlos.grohmann at gmail.com (Carlos Grohmann) Date: Thu, 23 Apr 2015 09:41:42 -0300 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: That was an interesting discussion, I'm sorry I missed it (should pay more attention...) I think that modules names should be descriptive. When I started learning GRASS (and GIS), back in my Masters, I knew what r.shaded.relief would do. I wouldn't be sure in the case of r.relief or r.shade. If we have r.local.relief in the addons, it's great but a new user might not know about this, so the name still can cause confusion. Making the names shorter doesn't necessarily make them better, IMO. I'd say r.shaded.relief should stay as it was. As for r.shade, I'd go with something like r.drape.shade or r.shade.drape (because that's what it is doing) or r.shade.mapping (but this could be confusing as well - is it mapping the shades?..) cheers Carlos On Thu, Apr 23, 2015 at 12:06 AM, Helena Mitasova wrote: > I agree with Carlos on this , I think r.shaded.relief was pretty clear > what it was doing. As I learned recently, r.relief indeed can be confused > with any of the numerous relief metrics. > > Helena > > > On Wednesday, April 22, 2015, Vaclav Petras wrote: > >> Hi Carlos, >> >> On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann < >> carlos.grohmann at gmail.com> wrote: >> > >> > Hi >> > >> > I just installed the latest pkg for GRASS 7 on OSX (nice splash screen >> BTW) >> > and r.shaded.relief is now just r.relief >> > >> > Is it too much if ask why this change? To me, r.shaded.relief is so >> much better, it describes the module. >> >> I did the rename after discussion with Michael Barton and Markus Neteler. >> We've tried to consider different names for several modules and picked the >> ones which seemed less confusing. See the discussion: >> >> http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html >> >> http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html >> >> > >> > r.relief might be confusing (is it to calculate some rellief-related >> parameter? >> >> I'm afraid that in case of these modules, basically anything can be >> confusing. Let us know what do you think after reading the discussion, so >> we have some more feedback. >> >> > local relief? other morphometric parameter?). >> >> BTW, there is r.local.relief in addons. >> >> Vaclav >> >> > >> > >> > best >> > >> > Carlos >> > >> > >> > >> > -- >> > Prof. Carlos Henrique Grohmann >> > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil >> > - Digital Terrain Analysis | GIS | Remote Sensing - >> > >> > http://carlosgrohmann.com >> > http://orcid.org/0000-0001-5073-5572 >> > ________________ >> > Can't stop the signal. >> > >> > _______________________________________________ >> > grass-dev mailing list >> > grass-dev at lists.osgeo.org >> > http://lists.osgeo.org/mailman/listinfo/grass-dev >> >> > > -- > Helena Mitasova > Associate Professor > Department of Marine, Earth and Atmospheric Sciences > North Carolina State University > 1125 Jordan Hall > NCSU Box 8208 > Raleigh, NC 27695-8208 > http://www4.ncsu.edu/~hmitaso/ > http://geospatial.ncsu.edu/ > > email: hmitaso at ncsu.edu > ph: 919-513-1327 (no voicemail) > fax 919 515-7802 > > -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of S?o Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/0000-0001-5073-5572 ________________ Can't stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Thu Apr 23 07:25:20 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Thu, 23 Apr 2015 10:25:20 -0400 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: On Thu, Apr 23, 2015 at 8:41 AM, Carlos Grohmann wrote: > > That was an interesting discussion, I'm sorry I missed it (should pay more attention...) > > I think that modules names should be descriptive. When I started learning GRASS (and GIS), back in my Masters, I knew what r.shaded.relief would do. I wouldn't be sure in the case of r.relief or r.shade. > If we have r.local.relief in the addons, it's great but a new user might not know about this, so the name still can cause confusion. > > Making the names shorter doesn't necessarily make them better, IMO. > > I'd say r.shaded.relief should stay as it was. > > As for r.shade, I'd go with something like r.drape.shade or r.shade.drape (because that's what it is doing) or r.shade.mapping (but this could be confusing as well - is it mapping the shades?..) Thanks for the comments, Carlos. I think the desire to have short names was definitively involved in the decision. Although they might be less readable they have different advantages. According to it's name I might see r.shaded.relief as something which shades the relief (r.relief+r.shade) but it just creates the shade from relief (r.relief). Also, r.relief, although not self-explanatory, does not invoke any association with relief metrics or relief-related parameters because I'm not familiar with these terms (also Google and Wikipedia seems to be quite ignorant about them). In any case, I should emphasize that although this is an important feedback, the discussion already happened and now it would be impossible or at least very hard to change it since we have already released 7.0.0. Vaclav > cheers > > Carlos > > > > > > > > > On Thu, Apr 23, 2015 at 12:06 AM, Helena Mitasova wrote: >> >> I agree with Carlos on this , I think r.shaded.relief was pretty clear what it was doing. As I learned recently, r.relief indeed can be confused with any of the numerous relief metrics. >> >> Helena >> >> >> On Wednesday, April 22, 2015, Vaclav Petras wrote: >>> >>> Hi Carlos, >>> >>> On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann < carlos.grohmann at gmail.com> wrote: >>> > >>> > Hi >>> > >>> > I just installed the latest pkg for GRASS 7 on OSX (nice splash screen BTW) >>> > and r.shaded.relief is now just r.relief >>> > >>> > Is it too much if ask why this change? To me, r.shaded.relief is so much better, it describes the module. >>> >>> I did the rename after discussion with Michael Barton and Markus Neteler. We've tried to consider different names for several modules and picked the ones which seemed less confusing. See the discussion: >>> >>> http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html >>> http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html >>> >>> > >>> > r.relief might be confusing (is it to calculate some rellief-related parameter? >>> >>> I'm afraid that in case of these modules, basically anything can be confusing. Let us know what do you think after reading the discussion, so we have some more feedback. >>> >>> > local relief? other morphometric parameter?). >>> >>> BTW, there is r.local.relief in addons. >>> >>> Vaclav >>> >>> > >>> > >>> > best >>> > >>> > Carlos >>> > >>> > >>> > >>> > -- >>> > Prof. Carlos Henrique Grohmann >>> > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil >>> > - Digital Terrain Analysis | GIS | Remote Sensing - >>> > >>> > http://carlosgrohmann.com >>> > http://orcid.org/0000-0001-5073-5572 >>> > ________________ >>> > Can?t stop the signal. >>> > >>> > _______________________________________________ >>> > grass-dev mailing list >>> > grass-dev at lists.osgeo.org >>> > http://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> >> >> -- >> Helena Mitasova >> Associate Professor >> Department of Marine, Earth and Atmospheric Sciences >> North Carolina State University >> 1125 Jordan Hall >> NCSU Box 8208 >> Raleigh, NC 27695-8208 >> http://www4.ncsu.edu/~hmitaso/ >> http://geospatial.ncsu.edu/ >> >> email: hmitaso at ncsu.edu >> ph: 919-513-1327 (no voicemail) >> fax 919 515-7802 >> > > > > -- > Prof. Carlos Henrique Grohmann > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > - Digital Terrain Analysis | GIS | Remote Sensing - > > http://carlosgrohmann.com > http://orcid.org/0000-0001-5073-5572 > ________________ > Can?t stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Thu Apr 23 07:38:47 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 23 Apr 2015 14:38:47 -0000 Subject: [GRASS-dev] [GRASS GIS] #2652: v.in.e00 In-Reply-To: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> References: <044.77b24f31e0438c0bc108c57482848395@osgeo.org> Message-ID: <059.cbf114b1845c18270a9a2ba76cb650bc@osgeo.org> #2652: v.in.e00 -------------------------+------------------------- Reporter: templar112 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Vector | Version: 7.0.0 Resolution: | Keywords: e00 CPU: x86-64 | Platform: MSWindows 8 -------------------------+------------------------- Changes (by annakrat): * keywords: => e00 Comment: I backported the changes in r65125. The rest is to decide if e00conv should be in extrabin folder. -- Ticket URL: GRASS GIS From wenzeslaus at gmail.com Thu Apr 23 08:21:06 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Thu, 23 Apr 2015 11:21:06 -0400 Subject: [GRASS-dev] Fwd: Re: [SAC] Upgrading Trac/SVN VM In-Reply-To: References: <20150417092825.GA31129@foehn.mgras.de> <20150422211554.GA2384@foehn.mgras.de> <20150422225224.GA3017@foehn.mgras.de> Message-ID: Trac 1.0.5. Live preview for the tickets, side-by-side wiki page live previews, clickable keywords in tickets! On Wed, Apr 22, 2015 at 7:01 PM, Markus Neteler wrote: > FYI > ---------- Forwarded message ---------- > From: "Martin Spott" > Date: Apr 23, 2015 12:52 AM > Subject: Re: [SAC] Upgrading Trac/SVN VM > To: "System Administration Committee Discussion/OSGeo" < > sac at lists.osgeo.org> > Cc: > > On Wed, Apr 22, 2015 at 11:15:54PM +0200, Martin Spott wrote: > > > I know the Trac web page is currently unavailable - I'm in the process > > of fixing it, > > The site should be running again - on Debian Squeeze (6.0). > By accident (mistake) I also upgraded Trac from 0.11.7 on Python2.5 to > 1.0.5 on Python2.6 and PostgreSQL from 8.3 to 8.4. I'm sure I broke > something, but at least the Trac pages which are listed on: > > http://trac.osgeo.org/ > > .... are looking functional to me. > > Please report errors, > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -------------------------------------------------------------------------- > _______________________________________________ > Sac mailing list > Sac at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/sac > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos.grohmann at gmail.com Thu Apr 23 09:39:41 2015 From: carlos.grohmann at gmail.com (Carlos Grohmann) Date: Thu, 23 Apr 2015 13:39:41 -0300 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: Well, maybe we can think on this again in the near future?.. I always think on my students and in people coming from the ArcGIS world.. If I were just beginning in GRASS, looking at the modules' names, I would definitely think that relief shading would be done with r.shade, not r.relief (which would give me the impression that it something related to a morphometric parameter - but that may be because I do work with geomorphometry..). Anyway, the menus descriptions are good and clear. It's just going to be a bit hard to get used to the new names after all these years.. best On Thu, Apr 23, 2015 at 11:25 AM, Vaclav Petras wrote: > On Thu, Apr 23, 2015 at 8:41 AM, Carlos Grohmann < > carlos.grohmann at gmail.com> wrote: > > > > That was an interesting discussion, I'm sorry I missed it (should pay > more attention...) > > > > I think that modules names should be descriptive. When I started > learning GRASS (and GIS), back in my Masters, I knew what r.shaded.relief > would do. I wouldn't be sure in the case of r.relief or r.shade. > > If we have r.local.relief in the addons, it's great but a new user might > not know about this, so the name still can cause confusion. > > > > Making the names shorter doesn't necessarily make them better, IMO. > > > > I'd say r.shaded.relief should stay as it was. > > > > As for r.shade, I'd go with something like r.drape.shade or > r.shade.drape (because that's what it is doing) or r.shade.mapping (but > this could be confusing as well - is it mapping the shades?..) > > Thanks for the comments, Carlos. I think the desire to have short names > was definitively involved in the decision. Although they might be less > readable they have different advantages. According to it's name I might see > r.shaded.relief as something which shades the relief (r.relief+r.shade) but > it just creates the shade from relief (r.relief). Also, r.relief, although > not self-explanatory, does not invoke any association with relief metrics > or relief-related parameters because I'm not familiar with these terms > (also Google and Wikipedia seems to be quite ignorant about them). > > In any case, I should emphasize that although this is an important > feedback, the discussion already happened and now it would be impossible or > at least very hard to change it since we have already released 7.0.0. > > Vaclav > > > cheers > > > > Carlos > > > > > > > > > > > > > > > > > > On Thu, Apr 23, 2015 at 12:06 AM, Helena Mitasova > wrote: > >> > >> I agree with Carlos on this , I think r.shaded.relief was pretty clear > what it was doing. As I learned recently, r.relief indeed can be confused > with any of the numerous relief metrics. > >> > >> Helena > >> > >> > >> On Wednesday, April 22, 2015, Vaclav Petras > wrote: > >>> > >>> Hi Carlos, > >>> > >>> On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann < > carlos.grohmann at gmail.com> wrote: > >>> > > >>> > Hi > >>> > > >>> > I just installed the latest pkg for GRASS 7 on OSX (nice splash > screen BTW) > >>> > and r.shaded.relief is now just r.relief > >>> > > >>> > Is it too much if ask why this change? To me, r.shaded.relief is so > much better, it describes the module. > >>> > >>> I did the rename after discussion with Michael Barton and Markus > Neteler. We've tried to consider different names for several modules and > picked the ones which seemed less confusing. See the discussion: > >>> > >>> http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html > >>> > http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html > >>> > >>> > > >>> > r.relief might be confusing (is it to calculate some rellief-related > parameter? > >>> > >>> I'm afraid that in case of these modules, basically anything can be > confusing. Let us know what do you think after reading the discussion, so > we have some more feedback. > >>> > >>> > local relief? other morphometric parameter?). > >>> > >>> BTW, there is r.local.relief in addons. > >>> > >>> Vaclav > >>> > >>> > > >>> > > >>> > best > >>> > > >>> > Carlos > >>> > > >>> > > >>> > > >>> > -- > >>> > Prof. Carlos Henrique Grohmann > >>> > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > >>> > - Digital Terrain Analysis | GIS | Remote Sensing - > >>> > > >>> > http://carlosgrohmann.com > >>> > http://orcid.org/0000-0001-5073-5572 > >>> > ________________ > >>> > Can't stop the signal. > >>> > > >>> > _______________________________________________ > >>> > grass-dev mailing list > >>> > grass-dev at lists.osgeo.org > >>> > http://lists.osgeo.org/mailman/listinfo/grass-dev > >>> > >> > >> > >> -- > >> Helena Mitasova > >> Associate Professor > >> Department of Marine, Earth and Atmospheric Sciences > >> North Carolina State University > >> 1125 Jordan Hall > >> NCSU Box 8208 > >> Raleigh, NC 27695-8208 > >> http://www4.ncsu.edu/~hmitaso/ > >> http://geospatial.ncsu.edu/ > >> > >> email: hmitaso at ncsu.edu > >> ph: 919-513-1327 (no voicemail) > >> fax 919 515-7802 > >> > > > > > > > > -- > > Prof. Carlos Henrique Grohmann > > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > > - Digital Terrain Analysis | GIS | Remote Sensing - > > > > http://carlosgrohmann.com > > http://orcid.org/0000-0001-5073-5572 > > ________________ > > Can't stop the signal. > > -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of S?o Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/0000-0001-5073-5572 ________________ Can't stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Thu Apr 23 10:18:31 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Thu, 23 Apr 2015 13:18:31 -0400 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: On Thu, Apr 23, 2015 at 12:39 PM, Carlos Grohmann wrote: > > Well, maybe we can think on this again in the near future?.. The issue is that we must keep API compatible in major version following semantic versioning (http://semver.org/). We can rename items in the menu (GUI) but not rename module (CLI and API) for 7 series. We can add new modules but having synonyms for modules might cause confusion. However, the situation now is a little bit special: 7.0.0 is first in the series and it was not fully adopted yet, so backwards compatibility within 7 series is not such an issue. However, we would have to be really sure we are doing the right thing. > I always think on my students and in people coming from the ArcGIS world.. If I were just beginning in GRASS, looking at the modules' names, I would definitely think that relief shading would be done with r.shade, not r.relief (which would give me the impression that it something related to a morphometric parameter - but that may be because I do work with geomorphometry..). Perhaps the basic descriptions in manual could be improved to direct you between r.relief and r|d.shade in case you find one and not the other. > Anyway, the menus descriptions are good and clear. It's just going to be a bit hard to get used to the new names after all these years.. Backwards compatibility between series (i.e. 7 with 6) is valuable but sometimes we must change in order to accommodate new features or have consistency (in this case, considering other related modules from the previous discussion). > best > > > On Thu, Apr 23, 2015 at 11:25 AM, Vaclav Petras wrote: >> >> On Thu, Apr 23, 2015 at 8:41 AM, Carlos Grohmann < carlos.grohmann at gmail.com> wrote: >> > >> > That was an interesting discussion, I'm sorry I missed it (should pay more attention...) >> > >> > I think that modules names should be descriptive. When I started learning GRASS (and GIS), back in my Masters, I knew what r.shaded.relief would do. I wouldn't be sure in the case of r.relief or r.shade. >> > If we have r.local.relief in the addons, it's great but a new user might not know about this, so the name still can cause confusion. >> > >> > Making the names shorter doesn't necessarily make them better, IMO. >> > >> > I'd say r.shaded.relief should stay as it was. >> > >> > As for r.shade, I'd go with something like r.drape.shade or r.shade.drape (because that's what it is doing) or r.shade.mapping (but this could be confusing as well - is it mapping the shades?..) >> >> Thanks for the comments, Carlos. I think the desire to have short names was definitively involved in the decision. Although they might be less readable they have different advantages. According to it's name I might see r.shaded.relief as something which shades the relief (r.relief+r.shade) but it just creates the shade from relief (r.relief). Also, r.relief, although not self-explanatory, does not invoke any association with relief metrics or relief-related parameters because I'm not familiar with these terms (also Google and Wikipedia seems to be quite ignorant about them). >> >> In any case, I should emphasize that although this is an important feedback, the discussion already happened and now it would be impossible or at least very hard to change it since we have already released 7.0.0. >> >> Vaclav >> >> > cheers >> > >> > Carlos >> > >> > >> > >> > >> > >> > >> > >> > >> > On Thu, Apr 23, 2015 at 12:06 AM, Helena Mitasova wrote: >> >> >> >> I agree with Carlos on this , I think r.shaded.relief was pretty clear what it was doing. As I learned recently, r.relief indeed can be confused with any of the numerous relief metrics. >> >> >> >> Helena >> >> >> >> >> >> On Wednesday, April 22, 2015, Vaclav Petras wrote: >> >>> >> >>> Hi Carlos, >> >>> >> >>> On Wed, Apr 22, 2015 at 8:44 AM, Carlos Grohmann < carlos.grohmann at gmail.com> wrote: >> >>> > >> >>> > Hi >> >>> > >> >>> > I just installed the latest pkg for GRASS 7 on OSX (nice splash screen BTW) >> >>> > and r.shaded.relief is now just r.relief >> >>> > >> >>> > Is it too much if ask why this change? To me, r.shaded.relief is so much better, it describes the module. >> >>> >> >>> I did the rename after discussion with Michael Barton and Markus Neteler. We've tried to consider different names for several modules and picked the ones which seemed less confusing. See the discussion: >> >>> >> >>> http://lists.osgeo.org/pipermail/grass-dev/2014-November/071904.html >> >>> http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r62845-in-grass-trunk-scripts-d-shadedmap-r-shadedmap-td5174184.html >> >>> >> >>> > >> >>> > r.relief might be confusing (is it to calculate some rellief-related parameter? >> >>> >> >>> I'm afraid that in case of these modules, basically anything can be confusing. Let us know what do you think after reading the discussion, so we have some more feedback. >> >>> >> >>> > local relief? other morphometric parameter?). >> >>> >> >>> BTW, there is r.local.relief in addons. >> >>> >> >>> Vaclav >> >>> >> >>> > >> >>> > >> >>> > best >> >>> > >> >>> > Carlos >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Prof. Carlos Henrique Grohmann >> >>> > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil >> >>> > - Digital Terrain Analysis | GIS | Remote Sensing - >> >>> > >> >>> > http://carlosgrohmann.com >> >>> > http://orcid.org/0000-0001-5073-5572 >> >>> > ________________ >> >>> > Can?t stop the signal. >> >>> > >> >>> > _______________________________________________ >> >>> > grass-dev mailing list >> >>> > grass-dev at lists.osgeo.org >> >>> > http://lists.osgeo.org/mailman/listinfo/grass-dev >> >>> >> >> >> >> >> >> -- >> >> Helena Mitasova >> >> Associate Professor >> >> Department of Marine, Earth and Atmospheric Sciences >> >> North Carolina State University >> >> 1125 Jordan Hall >> >> NCSU Box 8208 >> >> Raleigh, NC 27695-8208 >> >> http://www4.ncsu.edu/~hmitaso/ >> >> http://geospatial.ncsu.edu/ >> >> >> >> email: hmitaso at ncsu.edu >> >> ph: 919-513-1327 (no voicemail) >> >> fax 919 515-7802 >> >> >> > >> > >> > >> > -- >> > Prof. Carlos Henrique Grohmann >> > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil >> > - Digital Terrain Analysis | GIS | Remote Sensing - >> > >> > http://carlosgrohmann.com >> > http://orcid.org/0000-0001-5073-5572 >> > ________________ >> > Can?t stop the signal. >> > > > > -- > Prof. Carlos Henrique Grohmann > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > - Digital Terrain Analysis | GIS | Remote Sensing - > > http://carlosgrohmann.com > http://orcid.org/0000-0001-5073-5572 > ________________ > Can?t stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Thu Apr 23 11:13:49 2015 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 23 Apr 2015 20:13:49 +0200 Subject: [GRASS-dev] Fwd: Re: [SAC] Upgrading Trac/SVN VM In-Reply-To: References: <20150417092825.GA31129@foehn.mgras.de> <20150422211554.GA2384@foehn.mgras.de> <20150422225224.GA3017@foehn.mgras.de> Message-ID: On Thu, Apr 23, 2015 at 5:21 PM, Vaclav Petras wrote: > Trac 1.0.5. Live preview for the tickets, side-by-side wiki page live > previews, clickable keywords in tickets! Yes, really nice. And we could enhance the ticket overview reports to include the "keywords" column (I tried but didn't figure out a working syntax, perhaps the reports need to be redefined?). Markus From mlennert at club.worldonline.be Fri Apr 24 01:06:16 2015 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri, 24 Apr 2015 10:06:16 +0200 Subject: [GRASS-dev] GRASS 7: r.shaded.relief changed name? In-Reply-To: References: Message-ID: <5539F978.4010800@club.worldonline.be> On 23/04/15 16:25, Vaclav Petras wrote: > On Thu, Apr 23, 2015 at 8:41 AM, Carlos Grohmann > > wrote: > > > > That was an interesting discussion, I'm sorry I missed it (should pay > more attention...) > > > > I think that modules names should be descriptive. When I started > learning GRASS (and GIS), back in my Masters, I knew what > r.shaded.relief would do. I wouldn't be sure in the case of r.relief or > r.shade. > > If we have r.local.relief in the addons, it's great but a new user > might not know about this, so the name still can cause confusion. > > > > Making the names shorter doesn't necessarily make them better, IMO. > > > > I'd say r.shaded.relief should stay as it was. > > > > As for r.shade, I'd go with something like r.drape.shade or > r.shade.drape (because that's what it is doing) or r.shade.mapping (but > this could be confusing as well - is it mapping the shades?..) > > Thanks for the comments, Carlos. I think the desire to have short names > was definitively involved in the decision. Although they might be less > readable they have different advantages. According to it's name I might > see r.shaded.relief as something which shades the relief > (r.relief+r.shade) but it just creates the shade from relief (r.relief). > Also, r.relief, although not self-explanatory, does not invoke any > association with relief metrics or relief-related parameters because I'm > not familiar with these terms (also Google and Wikipedia seems to be > quite ignorant about them). > > In any case, I should emphasize that although this is an important > feedback, the discussion already happened and now it would be impossible > or at least very hard to change it since we have already released 7.0.0. As a side note: I think this also raises the question of how such changes are discussed and decided. I don't think many people realised that a thread entitled: "[GRASS-SVN] r62845 - in grass/trunk/scripts: . d.shadedmap r.shadedmap" discussed the renaming of modules. I would encourage that in the future we go through a process that is minutely more formalies, i.e. that once the discussion in such a thread has ripened a new thread is created with subject making it clear that there is a proposal for a significant renaming of modules. Nothing worth an RFC, just a some "good practice". Moritz From wenzeslaus at gmail.com Fri Apr 24 09:03:53 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Fri, 24 Apr 2015 12:03:53 -0400 Subject: [GRASS-dev] Fwd: Re: [SAC] Upgrading Trac/SVN VM In-Reply-To: References: <20150417092825.GA31129@foehn.mgras.de> <20150422211554.GA2384@foehn.mgras.de> <20150422225224.GA3017@foehn.mgras.de> Message-ID: On Thu, Apr 23, 2015 at 2:13 PM, Markus Neteler wrote: > > On Thu, Apr 23, 2015 at 5:21 PM, Vaclav Petras wrote: > > Trac 1.0.5. Live preview for the tickets, side-by-side wiki page live > > previews, clickable keywords in tickets! > > Yes, really nice. More: editing ticket comments (should be used if you do typo), changes since the last visit highlighted in the timeline > And we could enhance the ticket overview reports to include the > "keywords" column (I tried but didn't figure out a working syntax, > perhaps the reports need to be redefined?). I don't have an idea how this works but I definitively like the reports with keywords, although it is longer. I would also wish to refine the report with my parameters (turn report into query) but this does not seem to be possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Fri Apr 24 10:16:52 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 24 Apr 2015 17:16:52 -0000 Subject: [GRASS-dev] [GRASS GIS] #2661: sqlbuilder: verify button Message-ID: <041.3b1c4584121a21c9e1bb38f21e3f6d75@osgeo.org> #2661: sqlbuilder: verify button ------------------------------------------------+------------------------- Reporter: martinl | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 7.0.1 Component: wxGUI | Version: unspecified Keywords: attribute manager, dbmgr, wingrass | CPU: Unspecified Platform: MSWindows 7 | ------------------------------------------------+------------------------- On Windows there is badly placed 'Verify' button (located in upper-left corner of the window). -- Ticket URL: GRASS GIS From trac at osgeo.org Fri Apr 24 10:53:20 2015 From: trac at osgeo.org (GRASS GIS) Date: Fri, 24 Apr 2015 17:53:20 -0000 Subject: [GRASS-dev] [GRASS GIS] #2661: sqlbuilder: verify button In-Reply-To: <041.3b1c4584121a21c9e1bb38f21e3f6d75@osgeo.org> References: <041.3b1c4584121a21c9e1bb38f21e3f6d75@osgeo.org> Message-ID: <056.a7a905cb957b0062b56427173913763f@osgeo.org> #2661: sqlbuilder: verify button --------------------------+------------------------------------------------ Reporter: martinl | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 7.0.1 Component: wxGUI | Version: unspecified Resolution: | Keywords: attribute manager, dbmgr, wingrass CPU: Unspecified | Platform: MSWindows 7 --------------------------+------------------------------------------------ Comment (by annakrat): Try r65130. -- Ticket URL: GRASS GIS From nik at nikosalexandris.net Fri Apr 24 14:51:30 2015 From: nik at nikosalexandris.net (Nikos Alexandris) Date: Sat, 25 Apr 2015 00:51:30 +0300 Subject: [GRASS-dev] Limit in number of "variables" for r.mapcalc? Message-ID: <20150424215105.GA21959@tpx1c2g> Hi devs, is there a limit in the number of "variables" that r.mapcalc accepts within from 'eval'? If yes, how big is it? I am trying to feed r.mapcalc's eval with a fairly large number of pixel modifiers and, given that the final expression is a valid one, the execution ends with: debug=1 ended with error Process ended with non-zero return code -11. See errors in the (error) output. Thank you, Nikos From nik at nikosalexandris.net Fri Apr 24 15:09:06 2015 From: nik at nikosalexandris.net (Nikos Alexandris) Date: Sat, 25 Apr 2015 01:09:06 +0300 Subject: [GRASS-dev] Limit in g.message? was: Limit in number of "variables" for r.mapcalc? In-Reply-To: <20150424215105.GA21959@tpx1c2g> References: <20150424215105.GA21959@tpx1c2g> Message-ID: <20150424220906.GB21959@tpx1c2g> * Nikos Alexandris [2015-04-25 00:51:30 +0300]: > Hi devs, > > is there a limit in the number of "variables" that r.mapcalc accepts > within from 'eval'? If yes, how big is it? > > I am trying to feed r.mapcalc's eval with a fairly large number of pixel > modifiers and, given that the final expression is a valid one, the > execution ends with: > > debug=1 ended with error > Process ended with non-zero return code -11. See errors in the (error) > output. Problem resolved. As I tend to use g.message to print out almost everything while testing scripts, it seems I hit a limit in g.message this time! r.mapcalc has no problem dealing with the long and complex expression fed to eval. So the question is, is there a limit in g.message? Number of characters? I recall a similar question of mine regarding r.support, but I can't trace it back. Thanks, Nikos From p.vanbreugel at gmail.com Sat Apr 25 00:52:41 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Sat, 25 Apr 2015 09:52:41 +0200 Subject: [GRASS-dev] Any plans to port r.out.mbtiles to GRASS 7 Message-ID: Hi, I am looking at r.out.mbtiles, which looks like a very useful addon and would like to check if there are any plans to port this to python / GRASS GIS 7.0 (Hamish?)? Rgds, Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Sat Apr 25 04:23:52 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 25 Apr 2015 11:23:52 -0000 Subject: [GRASS-dev] [GRASS GIS] #2662: v.in.proj crashes on Windows Message-ID: <041.0cb86a72382d3c679e68ad3be22bbab2@osgeo.org> #2662: v.in.proj crashes on Windows ----------------------------------+--------------------------------- Reporter: martinl | Owner: grass-dev@? Type: defect | Status: new Priority: blocker | Milestone: 7.0.1 Component: LibGIS | Version: svn-releasebranch70 Keywords: v.in.proj, r.in.proj | CPU: Unspecified Platform: Unspecified | ----------------------------------+--------------------------------- `v.in.proj` crashes on Windows (epsg:4326 -> epsg:5514) {{{ D2/5: file open: read (mode = r) D2/5: G__read_Cell_head D2/5: G__read_Cell_head_array D3/5: region item: proj: 3 D3/5: region item: zone: 0 D3/5: region item: north: 935275:00:27.10224S ERROR: Syntax error in cell header }}} on source:grass/trunk/vector/v.in.ogr/main.c#L591 This issue has been apparently fixed in trunk (where it works). The last change of `get_window.c` is from 2014-12-29. Any idea when it was fixed (and backported to relbr70)? -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 25 07:45:15 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 25 Apr 2015 14:45:15 -0000 Subject: [GRASS-dev] [GRASS GIS] #346: v.in.ogr fails when ArcIDs list is longer than 40 characters In-Reply-To: <042.a521d4e17a13812ebbaacbccba36ccd6@osgeo.org> References: <042.a521d4e17a13812ebbaacbccba36ccd6@osgeo.org> Message-ID: <057.6487449116024baa1735c0660102c7ff@osgeo.org> #346: v.in.ogr fails when ArcIDs list is longer than 40 characters -----------------------+----------------------------- Reporter: dmahoney | Owner: grass-dev@? Type: defect | Status: new Priority: major | Milestone: 6.4.4 Component: Vector | Version: svn-trunk Resolution: | Keywords: v.in.ogr arcids CPU: All | Platform: All -----------------------+----------------------------- Comment (by neteler): OFTIntegerListlength enlarged in trunk in r65133 -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 25 08:21:41 2015 From: trac at osgeo.org (GRASS GIS) Date: Sat, 25 Apr 2015 15:21:41 -0000 Subject: [GRASS-dev] [GRASS GIS] #2662: v.in.proj crashes on Windows In-Reply-To: <041.0cb86a72382d3c679e68ad3be22bbab2@osgeo.org> References: <041.0cb86a72382d3c679e68ad3be22bbab2@osgeo.org> Message-ID: <056.fa887551db330a76b531be51b8a3906c@osgeo.org> #2662: v.in.proj crashes on Windows --------------------------+---------------------------------- Reporter: martinl | Owner: grass-dev@? Type: defect | Status: new Priority: blocker | Milestone: 7.0.1 Component: LibGIS | Version: svn-releasebranch70 Resolution: | Keywords: v.in.proj, r.in.proj CPU: Unspecified | Platform: Unspecified --------------------------+---------------------------------- Comment (by neteler): Not sure if that matters but there is this coverity scan report: {{{ *** CID 1262561: Unbounded source buffer (STRING_SIZE) /lib/gis/get_window.c: 65 in G_get_window() 59 if (regvar) { 60 char **tokens = G_tokenize(regvar, ";"); 61 G__read_Cell_head_array(tokens, &st->dbwindow, 0); 62 G_free_tokens(tokens); 63 } 64 else { >>> CID 1262561: Unbounded source buffer (STRING_SIZE) >>> Assigning: "wind" = "getenv". "wind" is now tainted. 65 char *wind = getenv("WIND_OVERRIDE"); 66 if (wind) 67 G_get_element_window(&st->dbwindow, "windows", wind, G_mapset()); 68 else 69 G_get_element_window(&st->dbwindow, "", "WIND", G_mapset()); 70 } }}} -- Ticket URL: GRASS GIS From Michael.Barton at asu.edu Sat Apr 25 10:12:13 2015 From: Michael.Barton at asu.edu (Michael Barton) Date: Sat, 25 Apr 2015 17:12:13 +0000 Subject: [GRASS-dev] grass-dev Digest, Vol 110, Issue 36 In-Reply-To: References: Message-ID: <939CA769-B875-4F52-A1B9-76B7AA45F4E8@asu.edu> The renaming and regularization of modules for the GRASS 7 release took place over multiple months IIRC. Martin and Markus sent out repeated requests/invitation for comment during this time. There was a specific discussion thread for this but there was not a lot of comment for most of the modules. The discussion of whether and how to rename the module that is now called r.relief was on the dev list and lengthy, with quite a few people weighing in with different opinions (unlike most other renamed modules). There was a lengthy discussion thread for this too. I agree that the process needs to be open and transparent. But in this case, my recollection is that it was. Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Apr 24, 2015, at 12:01 PM, grass-dev-request at lists.osgeo.org wrote: From: Moritz Lennert > Subject: Re: [GRASS-dev] GRASS 7: r.shaded.relief changed name? Date: April 24, 2015 at 1:06:16 AM MST To: Vaclav Petras >, Carlos Grohmann > Cc: Helena Mitasova >, grass-dev > On 23/04/15 16:25, Vaclav Petras wrote: On Thu, Apr 23, 2015 at 8:41 AM, Carlos Grohmann > wrote: > > That was an interesting discussion, I'm sorry I missed it (should pay more attention...) > > I think that modules names should be descriptive. When I started learning GRASS (and GIS), back in my Masters, I knew what r.shaded.relief would do. I wouldn't be sure in the case of r.relief or r.shade. > If we have r.local.relief in the addons, it's great but a new user might not know about this, so the name still can cause confusion. > > Making the names shorter doesn't necessarily make them better, IMO. > > I'd say r.shaded.relief should stay as it was. > > As for r.shade, I'd go with something like r.drape.shade or r.shade.drape (because that's what it is doing) or r.shade.mapping (but this could be confusing as well - is it mapping the shades?..) Thanks for the comments, Carlos. I think the desire to have short names was definitively involved in the decision. Although they might be less readable they have different advantages. According to it's name I might see r.shaded.relief as something which shades the relief (r.relief+r.shade) but it just creates the shade from relief (r.relief). Also, r.relief, although not self-explanatory, does not invoke any association with relief metrics or relief-related parameters because I'm not familiar with these terms (also Google and Wikipedia seems to be quite ignorant about them). In any case, I should emphasize that although this is an important feedback, the discussion already happened and now it would be impossible or at least very hard to change it since we have already released 7.0.0. As a side note: I think this also raises the question of how such changes are discussed and decided. I don't think many people realised that a thread entitled: "[GRASS-SVN] r62845 - in grass/trunk/scripts: . d.shadedmap r.shadedmap" discussed the renaming of modules. I would encourage that in the future we go through a process that is minutely more formalies, i.e. that once the discussion in such a thread has ripened a new thread is created with subject making it clear that there is a proposal for a significant renaming of modules. Nothing worth an RFC, just a some "good practice". Moritz -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Sat Apr 25 17:57:10 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 26 Apr 2015 00:57:10 -0000 Subject: [GRASS-dev] [GRASS GIS] #2663: Add test for r.watershed module Message-ID: <044.1b3c07920e148ec900c6018497f89137@osgeo.org> #2663: Add test for r.watershed module -------------------------+------------------------- Reporter: swendel621 | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.0.1 Component: Default | Version: unspecified Keywords: | CPU: Unspecified Platform: Unspecified | -------------------------+------------------------- I built a test for the r.watershed module to be incorporated into the software that can be found here: https://github.com/swwendel/GRASS-r.Watershed-UnitTest Thanks! Stephanie Wendel -- Ticket URL: GRASS GIS From trac at osgeo.org Sat Apr 25 18:20:39 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 26 Apr 2015 01:20:39 -0000 Subject: [GRASS-dev] [GRASS GIS] #2664: The r.watershed module documentation has the wrong value for cells that do not get included in a complete watershed. Message-ID: <044.4bda1938bf6f3f207d2f9e2806413b50@osgeo.org> #2664: The r.watershed module documentation has the wrong value for cells that do not get included in a complete watershed. -------------------------------------+------------------------- Reporter: swendel621 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Docs | Version: 7.0.0 Keywords: r.watershed, basin, doc | CPU: All Platform: All | -------------------------------------+------------------------- In the current online r.watershed module's help documentation, there is a conflicting statement to the output generated for the basin parameter. [http://grass.osgeo.org/grass71/manuals/r.watershed.html] In the text it says, "0 values indicate that the cell is not part of a complete watershed basin in the current geographic region." If I run r.watershed on the Elevation sample data and set the threshold to 10000, the output basin will have areas on the edges that do not generate a basin. The values of these areas are null instead of 0 like the documentation makes it sounds like it should get. It makes sense for the values to be null instead of 0 so the documentation needs to be updated. -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 26 00:12:11 2015 From: trac at osgeo.org (GRASS GIS) Date: Sun, 26 Apr 2015 07:12:11 -0000 Subject: [GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory In-Reply-To: <042.bad2f4c82fb8c43b00d5a421daa8482f@osgeo.org> References: <042.bad2f4c82fb8c43b00d5a421daa8482f@osgeo.org> Message-ID: <057.2db2cb6ebeac320bae82335e596250f6@osgeo.org> #2045: r.to.vect: use less memory --------------------------+------------------------- Reporter: mlennert | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: | Keywords: r.to.vect CPU: Unspecified | Platform: Unspecified --------------------------+------------------------- Comment (by Madi): Hi, reported also here: http://lists.osgeo.org/pipermail/grass- user/2015-April/072315.html I tried to vectorize (r.to.vect) a very large raster: Total Cells: 4817298170 The option GRASS_VECTOR_LOWMEM slowed down the computation, however eventually it yielded Killed0000. The topology was not built correctly. Not sure if this is a bug report rather than enhancement wish? -- Ticket URL: GRASS GIS From trac at osgeo.org Sun Apr 26 21:19:09 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 27 Apr 2015 04:19:09 -0000 Subject: [GRASS-dev] [GRASS GIS] #2663: Add test for r.watershed module In-Reply-To: <044.1b3c07920e148ec900c6018497f89137@osgeo.org> References: <044.1b3c07920e148ec900c6018497f89137@osgeo.org> Message-ID: <059.a45bd61d33d2a0e89bde91fcbf4a41f7@osgeo.org> #2663: Add test for r.watershed module --------------------------+-------------------------------- Reporter: swendel621 | Owner: wenzeslaus Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Tests | Version: unspecified Resolution: | Keywords: patch, r.watershed CPU: Unspecified | Platform: Unspecified --------------------------+-------------------------------- Changes (by wenzeslaus): * owner: grass-dev@? => wenzeslaus * keywords: => patch, r.watershed * component: Default => Tests * milestone: 7.0.1 => 7.1.0 Comment: I committed the test together with few style-related changes in r65145. Thanks, Stephanie! I suggest to close the ticket after the the automated run is successful. For completeness, I'm attaching file with changes between original and the version I committed and here are also the steps I used for integrating it and testing it (GRASS GIS session active): {{{ #!bash # prepare dir and files cd raster/r.watershed/ mkdir testsuite geany r_watershed_test. # add to svn cd .. svn add testsuite /script/in/addons/tools/module_svn_propset.sh testsuite/r_watershed_test.py cd testsuite # run the test python r_watershed_test.py # automatically introduce as much from PEP8 as possible autopep8 -i r_watershed_test.py # check the Python style and syntax pep8 r_watershed_test.py pylint r_watershed_test.py # edit the file accordingly # run the test again python r_watershed_test.py # publish changes svn st svn commit -m "r.watershed: ..." -- Ticket URL: GRASS GIS From trac at osgeo.org Mon Apr 27 00:09:06 2015 From: trac at osgeo.org (GRASS GIS) Date: Mon, 27 Apr 2015 07:09:06 -0000 Subject: [GRASS-dev] [GRASS GIS] #2577: d.info: entire screen version frame In-Reply-To: <041.fde9a375788935eac60e207670cd5412@osgeo.org> References: <041.fde9a375788935eac60e207670cd5412@osgeo.org> Message-ID: <056.16d1aba6d6c5603d683520b22dbecf20@osgeo.org> #2577: d.info: entire screen version frame --------------------------+-------------------------------- Reporter: martinl | Owner: grass-dev@? Type: defect | Status: closed Priority: normal | Milestone: 7.0.1 Component: Display | Version: svn-trunk Resolution: fixed | Keywords: d.info, d.rast.leg CPU: Unspecified | Platform: Unspecified --------------------------+-------------------------------- Changes (by neteler): * keywords: d.info => d.info, d.rast.leg * milestone: 7.0.0 => 7.0.1 Comment: BTW: The changes broke d.rast.leg. Fixed in trunk r65147 and relbranch70 r65148. -- Ticket URL: GRASS GIS From glynn at gclements.plus.com Mon Apr 27 04:16:48 2015 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon, 27 Apr 2015 12:16:48 +0100 Subject: [GRASS-dev] Limit in g.message? was: Limit in number of "variables" for r.mapcalc? In-Reply-To: <20150424220906.GB21959@tpx1c2g> References: <20150424215105.GA21959@tpx1c2g> <20150424220906.GB21959@tpx1c2g> Message-ID: <21822.6816.164521.786918@cerise.gclements.plus.com> Nikos Alexandris wrote: > So the question is, is there a limit in g.message? Number of characters? g.message takes the message via a command-line argument, so it's limited to any system-imposed limit on the length of an individual argument or the combined length of the arguments. But more significantly, G_message() etc use an internal buffer of 2000 bytes. A message longer than that probably won't work and may well cause the g.message to crash. -- Glynn Clements From neteler at osgeo.org Mon Apr 27 04:24:20 2015 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 27 Apr 2015 13:24:20 +0200 Subject: [GRASS-dev] Limit in g.message? was: Limit in number of "variables" for r.mapcalc? In-Reply-To: <21822.6816.164521.786918@cerise.gclements.plus.com> References: <20150424215105.GA21959@tpx1c2g> <20150424220906.GB21959@tpx1c2g> <21822.6816.164521.786918@cerise.gclements.plus.com> Message-ID: On Mon, Apr 27, 2015 at 1:16 PM, Glynn Clements wrote: > But more significantly, G_message() etc use an internal buffer of 2000 > bytes. A message longer than that probably won't work and may well > cause the g.message to crash. How about (ab)using GPATH_MAX (include/gis.h) which is 4096 chars long and using it in general/g.message/main.c as well to avoid a buffer overflow? Markus From matejkrejci at gmail.com Tue Apr 28 11:16:45 2015 From: matejkrejci at gmail.com (Matej Krejci) Date: Tue, 28 Apr 2015 20:16:45 +0200 Subject: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS In-Reply-To: References: Message-ID: Hi, Thanks for the chance to participate on GSOC 2015. The page about project is on wiki site[1]. Thank you for ideas and notes in advance. Matej [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata 2015-03-11 1:55 GMT+01:00 Matej Krejci : > Hi all, > > Last GSOC I was working on ISO based metadata management for GRASS. In > this term I was created 'package' wx.metadata which is currently available > in GRASS add-ons. This part was essential. During playing with > possibilities of implementation I did a draft of metadata catalogue which > is the main task of current GSOC topic[1]. Moreover to implement additional > functions (see list[1]) for current metadata modules is more than suitable. > Since last GSOC I am still slightly in coding for GRASS and I like to > continue in this topic. Please let me know if the topic is still free. > > Thanks in advance, > Matej > > > [1] http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS > ------------- dal?? ??st --------------- HTML p??loha byla odstran?na... URL: From doug_newcomb at fws.gov Tue Apr 28 11:24:03 2015 From: doug_newcomb at fws.gov (Newcomb, Doug) Date: Tue, 28 Apr 2015 14:24:03 -0400 Subject: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS In-Reply-To: References: Message-ID: Thank you for working on this! :-) Doug On Tue, Apr 28, 2015 at 2:16 PM, Matej Krejci wrote: > Hi, > Thanks for the chance to participate on GSOC 2015. The page about project > is on wiki site[1]. Thank you for ideas and notes in advance. > > Matej > > [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata > > 2015-03-11 1:55 GMT+01:00 Matej Krejci : > >> Hi all, >> >> Last GSOC I was working on ISO based metadata management for GRASS. In >> this term I was created 'package' wx.metadata which is currently available >> in GRASS add-ons. This part was essential. During playing with >> possibilities of implementation I did a draft of metadata catalogue which >> is the main task of current GSOC topic[1]. Moreover to implement additional >> functions (see list[1]) for current metadata modules is more than suitable. >> Since last GSOC I am still slightly in coding for GRASS and I like to >> continue in this topic. Please let me know if the topic is still free. >> >> Thanks in advance, >> Matej >> >> >> [1] >> http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS >> > > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -- Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newcomb at fws.gov --------------------------------------------------------------------------------------------------------- The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.vanbreugel at gmail.com Tue Apr 28 11:55:01 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Tue, 28 Apr 2015 20:55:01 +0200 Subject: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS In-Reply-To: References: Message-ID: Is the addon working in GRASS 7.1? I can't compile it. On Tue, Apr 28, 2015 at 8:16 PM, Matej Krejci wrote: > Hi, > Thanks for the chance to participate on GSOC 2015. The page about project > is on wiki site[1]. Thank you for ideas and notes in advance. > > Matej > > [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata > > 2015-03-11 1:55 GMT+01:00 Matej Krejci : > >> Hi all, >> >> Last GSOC I was working on ISO based metadata management for GRASS. In >> this term I was created 'package' wx.metadata which is currently available >> in GRASS add-ons. This part was essential. During playing with >> possibilities of implementation I did a draft of metadata catalogue which >> is the main task of current GSOC topic[1]. Moreover to implement additional >> functions (see list[1]) for current metadata modules is more than suitable. >> Since last GSOC I am still slightly in coding for GRASS and I like to >> continue in this topic. Please let me know if the topic is still free. >> >> Thanks in advance, >> Matej >> >> >> [1] >> http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS >> > > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glynn at gclements.plus.com Tue Apr 28 14:41:15 2015 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue, 28 Apr 2015 22:41:15 +0100 Subject: [GRASS-dev] Limit in g.message? was: Limit in number of "variables" for r.mapcalc? In-Reply-To: References: <20150424215105.GA21959@tpx1c2g> <20150424220906.GB21959@tpx1c2g> <21822.6816.164521.786918@cerise.gclements.plus.com> Message-ID: <21823.65147.315594.610214@cerise.gclements.plus.com> Markus Neteler wrote: > > But more significantly, G_message() etc use an internal buffer of 2000 > > bytes. A message longer than that probably won't work and may well > > cause the g.message to crash. > > How about (ab)using GPATH_MAX (include/gis.h) which is 4096 chars long > and using it in > general/g.message/main.c as well to avoid a buffer overflow? Having g.message limit the length of a message would work for g.message. For G_message() etc, using vsnprintf() would work, but that's C99. G_vasprintf() should work, but our private implementation (used if asprintf() doesn't exist) also requires C99. -- Glynn Clements From trac at osgeo.org Tue Apr 28 14:46:17 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 28 Apr 2015 21:46:17 -0000 Subject: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE In-Reply-To: <041.93f699efbd403e30f50830a445d0865d@osgeo.org> References: <041.93f699efbd403e30f50830a445d0865d@osgeo.org> Message-ID: <056.907b967055f28837dc3762fecbeecf2c@osgeo.org> #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --------------------------+------------------------------------------- Reporter: neteler | Owner: grass-dev@? Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0 Component: Raster | Version: svn-trunk Resolution: | Keywords: compression, r.compress, null CPU: Unspecified | Platform: All --------------------------+------------------------------------------- Comment (by glynn): Replying to [comment:15 neteler]: > back to this topic: Here on our system I found > 1.7TB of NULL files in a single location, all > uncompressed. How large are the null files compared to the cell/fcell files? > What about having a "null2" file which is compressed and with index. If present, fine, otherwise use the uncompressed well known null file format? That's probably not a great deal of work, but as with any such change, we need to consider the migration strategy. If we just start creating compressed null files, mapsets will cease to be usable with older versions. -- Ticket URL: GRASS GIS From trac at osgeo.org Tue Apr 28 15:36:33 2015 From: trac at osgeo.org (GRASS GIS) Date: Tue, 28 Apr 2015 22:36:33 -0000 Subject: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE In-Reply-To: <041.93f699efbd403e30f50830a445d0865d@osgeo.org> References: <041.93f699efbd403e30f50830a445d0865d@osgeo.org> Message-ID: <056.74fb7349379e2648d103b638e148dc17@osgeo.org> #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --------------------------+------------------------------------------- Reporter: neteler | Owner: grass-dev@? Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0 Component: Raster | Version: svn-trunk Resolution: | Keywords: compression, r.compress, null CPU: Unspecified | Platform: All --------------------------+------------------------------------------- Comment (by neteler): Replying to [comment:16 glynn]: > How large are the null files compared to the cell/fcell files? * With MODIS LST data, the null files are between 1.7 and 7.6 times larger than the cell files (we store the LST maps in deg C * 100 as integer to save disk space). * With 100k random points, the null file is 7.1 times larger than the fcell map * With the EU 25m DEM, the null file is way smaller that the derived aspect map (17% of the DEM fcell file) > > What about having a "null2" file which is compressed and with index. If present, fine, otherwise use the uncompressed well known null file format? > > That's probably not a great deal of work, but as with any such change, we need to consider the migration strategy. If we just start creating compressed null files, mapsets will cease to be usable with older versions. Right but this could be covered with an addon/new script in G6 and earlier (as v.build does for vector data). -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 29 01:01:28 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 29 Apr 2015 08:01:28 -0000 Subject: [GRASS-dev] [GRASS GIS] #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) Message-ID: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) -------------------------------------------------+------------------------- Reporter: santipardo | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Display | Version: 7.0.0 Keywords: d.mon, d.vect, d.rast, python, | CPU: x86-64 script, bash | Platform: All | -------------------------------------------------+------------------------- ''(I copy here this question from GIS.stackexhange, related to a possible bug when calling d.* modules from a script)'' Do d.* commands from GRASS GIS 7.0 run from a python script? I'm trying with this code: {{{ import grass.script as grass grass.run_command('d.mon', start="wx3", resolution = '1') grass.run_command('d.mon', select="wx3") grass.run_command('d.rast', map="M01relief") grass.run_command('d.mon', select="wx3") grass.run_command('d.vect', map="M03PTEtramos", color="black", width='2') }}} When executing the complete script, the wx3 monitor starts, but remains empty. However, if I paste the commands one by one in GRASS Python Command-line, I get the layers drawn in the monitor. And using Cairo driver, I also get the layers drawn in a PNG file (directly from the script). In the aforementioned Python code, the monitor seems not to apply the code, because if I check for the monitor commands, I get no info: {{{ grass.run_command('d.mon', flags="c") [Empty output] }}} (The monitor wx3 opens and remains empty) Using a Bash script, the monitor is again empty: {{{ d.mon start=wx3 resolution=1 d.rast map=M01relief d.vect map=M03PTEtramos color=black width=2 d.redraw }}} But if I ask then for the list of commands I get results: {{{ d.mon -c Enlistar comandos para el monitor : d.rast map="M01relief" bgcolor="white" d.vect map="M03PTEtramos" layer="1" display="shape" type="point,line,boundary,area,face" color="black" fill_color="200:200:200" width=2 width_scale=1 icon="basic/x" size=5 label_layer="1" label_color="red" label_bgcolor="none" label_bcolor="none" label_size=8 xref="left" yref="center" }}} Actually, doing d.redraw from command line (not from the script), shows the map. The problem happens both in Linux Mint 64 bits and Windows7 64 bits (the second running in a VirtualBox machine) -- Ticket URL: GRASS GIS From p.vanbreugel at gmail.com Wed Apr 29 01:53:11 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Wed, 29 Apr 2015 10:53:11 +0200 Subject: [GRASS-dev] v.db.addtable turns column headers in lower case Message-ID: If I add a new table to a vector layer, column names are always in lower case, even if defined with capital letters. For example: {{{v.db.addtable map=test table=test columns="TEST1 INTEGER,TEST2 VARCHAR(25)"}}} Results in a table with the columns "cat", "test1", "test2". Is this intentional? Adding columns to a table withv.db.addcolumn does not show this behavious (i.e., it will retain capitalization of column headers). -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Wed Apr 29 05:00:58 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 29 Apr 2015 12:00:58 -0000 Subject: [GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory In-Reply-To: <042.bad2f4c82fb8c43b00d5a421daa8482f@osgeo.org> References: <042.bad2f4c82fb8c43b00d5a421daa8482f@osgeo.org> Message-ID: <057.3c9b0ed3bd0c6009a3691c202b9a2d07@osgeo.org> #2045: r.to.vect: use less memory --------------------------+------------------------- Reporter: mlennert | Owner: grass-dev@? Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: | Keywords: r.to.vect CPU: Unspecified | Platform: Unspecified --------------------------+------------------------- Comment (by martin): Hah, I tried to vectorize all of NLCD2011, which is 16832104560 cells in size, in one rush and found this to be a highly impracticable approach. The process (GRASS 7.1 trunk of late 2014) ran out of memory on a machine with more than 100 GByte of main mem and GRASS_VECTOR_LOWMEM didn't make any substantial difference.[[BR]] Finally I decided to cut the job into many small tiles of approx. 33M cells each (which represents approx. 2x2 degrees in North American AEA) and this turned out to work pretty well - not only in the vectorization but also in the subsequent vector post-processing stage. See here for a sample of the the result: http://mapserver.flightgear.org/map/?lon=-99.93544&lat=34.62565&zoom=6 -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 29 05:53:42 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 29 Apr 2015 12:53:42 -0000 Subject: [GRASS-dev] [GRASS GIS] #2662: v.in.proj crashes on Windows In-Reply-To: <041.0cb86a72382d3c679e68ad3be22bbab2@osgeo.org> References: <041.0cb86a72382d3c679e68ad3be22bbab2@osgeo.org> Message-ID: <056.7f4132da7ceefa6abd67b1db49843ae4@osgeo.org> #2662: v.in.proj crashes on Windows --------------------------+---------------------------------- Reporter: martinl | Owner: grass-dev@? Type: defect | Status: new Priority: blocker | Milestone: 7.0.1 Component: LibGIS | Version: svn-releasebranch70 Resolution: | Keywords: v.in.proj, r.in.proj CPU: Unspecified | Platform: Unspecified --------------------------+---------------------------------- Comment (by martinl): I can confirm this bug also in 7.0.1svn. BTW, daily winGRASS builds for 7.0.1svn are newly available at (1) (1) http://wingrass.fsv.cvut.cz/grass70/ -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 29 10:17:55 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 29 Apr 2015 17:17:55 -0000 Subject: [GRASS-dev] [GRASS GIS] #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) In-Reply-To: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> References: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> Message-ID: <059.f4a24a96fc9e37169cd86882f17ddbbb@osgeo.org> #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) -------------------------+------------------------------------------------- Reporter: santipardo | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Display | Version: 7.0.0 Resolution: | Keywords: d.mon, d.vect, d.rast, python, | script, bash CPU: x86-64 | Platform: All -------------------------+------------------------------------------------- Comment (by santipardo): This is weird. The commands are written to the cmd file of the monitor (e.g.: .tmp/24518.0.cmd): {{{ d.rast map="M01relief" bgcolor="white" d.vect map="M03PTEtramos" layer="1" display="shape" type="point,line,boundary,area,face" color="black" fill_color="200:200:200" width=2 width_scale=1 icon="basic/x" size=5 label_layer="1" label_color="red" label_bgcolor="none" label_bcolor="none" label_size=8 xref="left" yref="center" }}} But I do not get the layers shown until I manually open the file (in a text editor) and save it. Using some python code to open, edit and save the trick doesn't work: {{{ with open(rutamon, 'a') as comandos: comandos.write('d.redraw') comandos.close() }}} Here I open the file in append mode, and add a line for 'd.redraw'. But it doesn't work, I have to open and save manually the file... -- Ticket URL: GRASS GIS From trac at osgeo.org Wed Apr 29 10:57:40 2015 From: trac at osgeo.org (GRASS GIS) Date: Wed, 29 Apr 2015 17:57:40 -0000 Subject: [GRASS-dev] [GRASS GIS] #2666: GRASS 7 r.horizon outputting single file for mode 2 Message-ID: <042.d83eae9423bea0eda081ea0cfbacebca@osgeo.org> #2666: GRASS 7 r.horizon outputting single file for mode 2 -------------------------+------------------------- Reporter: bdmorri2 | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Raster | Version: 7.0.0 Keywords: r.horizon | CPU: x86-64 Platform: MSWindows 7 | -------------------------+------------------------- When I run r.horizon in GRASS 7.0.0 in mode 2 I am only getting a raster output for the last angle that was calculated. When I use r.horizon in GRASS 6.4.3 I do not have this problem. I am using the same code that I used for 6.4.3 in 7.0.0. I have also tried using the GUI to see if there is a new parameter that I am not aware of that must be checked to return all of the rasters that were calculated. This is the code that I used for both versions of GRASS: r.sun -p -m --overwrite --verbose elevation=dem_mos2 at PERMANENT aspect=aspect at bdmorri2 slope=slope at bdmorri2 beam_rad=beam_jan diff_rad=dif_jan glob_rad=total_jan day=15 Can someone either help with the bug or inform me of my own error for running this command? -- Ticket URL: GRASS GIS From matejkrejci at gmail.com Wed Apr 29 12:53:21 2015 From: matejkrejci at gmail.com (Matej Krejci) Date: Wed, 29 Apr 2015 21:53:21 +0200 Subject: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS In-Reply-To: References: Message-ID: Now it should work. The problem was in modification/remove of GuiModuleMain from core.utils. 2015-04-28 20:55 GMT+02:00 Paulo van Breugel : > Is the addon working in GRASS 7.1? I can't compile it. > > > On Tue, Apr 28, 2015 at 8:16 PM, Matej Krejci > wrote: > >> Hi, >> Thanks for the chance to participate on GSOC 2015. The page about project >> is on wiki site[1]. Thank you for ideas and notes in advance. >> >> Matej >> >> [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata >> >> 2015-03-11 1:55 GMT+01:00 Matej Krejci : >> >>> Hi all, >>> >>> Last GSOC I was working on ISO based metadata management for GRASS. In >>> this term I was created 'package' wx.metadata which is currently available >>> in GRASS add-ons. This part was essential. During playing with >>> possibilities of implementation I did a draft of metadata catalogue which >>> is the main task of current GSOC topic[1]. Moreover to implement additional >>> functions (see list[1]) for current metadata modules is more than suitable. >>> Since last GSOC I am still slightly in coding for GRASS and I like to >>> continue in this topic. Please let me know if the topic is still free. >>> >>> Thanks in advance, >>> Matej >>> >>> >>> [1] >>> http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS >>> >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev >> > > ------------- dal?? ??st --------------- HTML p??loha byla odstran?na... URL: From p.vanbreugel at gmail.com Wed Apr 29 13:02:59 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Wed, 29 Apr 2015 22:02:59 +0200 Subject: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS In-Reply-To: References: Message-ID: <554138F3.4050504@gmail.com> Hi Matej Thanks for the quick reply. I did indeed manage to install it now. However, when trying to run g.gui.metadata, I got the error message below: Installation of successfully finished (Wed Apr 29 21:58:43 2015) Command finished (8 sec) Traceback (most recent call last): File "/usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_cor e/prompt.py", line 263, in OnItemSelected self.cmdDesc = gtask.parse_interface(cmd) File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr ipt/task.py", line 509, in parse_interface tree = etree.fromstring(get_interface_description(name)) File "/usr/local/grass7/grass-7.1.svn/etc/python/grass/scr ipt/task.py", line 493, in get_interface_description "\n\nDetails: %(det)s") % {'cmd': cmd, 'det': e} grass.exceptions . ScriptError : Unable to fetch interface description for command 'g.mui.metadata'. Details: [Errno 2] No such file or directory Any idea? Best wishes Paulo On 29-04-15 21:53, Matej Krejci wrote: > Now it should work. The problem was in modification/remove > of GuiModuleMain from core.utils. > > 2015-04-28 20:55 GMT+02:00 Paulo van Breugel >: > > Is the addon working in GRASS 7.1? I can't compile it. > > > On Tue, Apr 28, 2015 at 8:16 PM, Matej Krejci > > wrote: > > Hi, > Thanks for the chance to participate on GSOC 2015. The page > about project is on wiki site[1]. Thank you for ideas and > notes in advance. > > Matej > > [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata > > 2015-03-11 1:55 GMT+01:00 Matej Krejci >: > > Hi all, > > Last GSOC I was working on ISO based metadata management > for GRASS. In this term I was created 'package' > wx.metadata which is currently available in GRASS add-ons. > This part was essential. During playing with possibilities > of implementation I did a draft of metadata catalogue > which is the main task of current GSOC topic[1]. Moreover > to implement additional functions (see list[1]) for > current metadata modules is more than suitable. > Since last GSOC I am still slightly in coding for GRASS > and I like to continue in this topic. Please let me know > if the topic is still free. > > Thanks in advance, > Matej > > > [1] > http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS > > > > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Wed Apr 29 14:56:22 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 29 Apr 2015 17:56:22 -0400 Subject: [GRASS-dev] t.rast.aggregate test mysteriously worked one day Message-ID: I've noticed that t.rast.aggregate "relative" test succeeded one day but generally fails: http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-27-13-32/report_for_nc_spm_08_grass7_nc/temporal/t.rast.aggregate/test_aggregation_relative/index.html http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-28-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.aggregate/test_aggregation_relative/index.html http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-04-29-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.rast.aggregate/test_aggregation_relative/index.html When I run it locally: # in grass session in a new mapset cd temporal/t.rast.aggregate/testsuite python test_aggregation_relative.py I get these errors: ERROR: Unable to make mapset element cell_misc/b_3 (/grassdata/nc_spm_testing/practice5/cell_misc/b_3): File exists ERROR: Unable to make mapset element cell_misc/b_3 (/grassdata/nc_spm_testing/practice5/cell_misc/b_3): File exists b_3 is the same name which is visible in (different) error messages in the tests: ERROR: Unable to update raster map . The map does not exist. ERROR: Unsupported relative time unit type for raster map : None I looked to the test but I was not sucesful. If somebody would like to look at it, remember that tearDownClass class method runs just once after all test_ methods are executed while tearDown method runs after each test_ method. Also remember that the order of runs is undefined. Perhaps the error messages needs to be enhanced in the actual code. Vaclav -------------- next part -------------- An HTML attachment was scrubbed... URL: From trac at osgeo.org Thu Apr 30 00:57:06 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 30 Apr 2015 07:57:06 -0000 Subject: [GRASS-dev] [GRASS GIS] #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) In-Reply-To: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> References: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> Message-ID: <059.7fbbb2078bb37123dfc97bba5aecad61@osgeo.org> #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) -------------------------+------------------------------------------------- Reporter: santipardo | Owner: grass-dev@? Type: defect | Status: new Priority: normal | Milestone: 7.0.1 Component: Display | Version: 7.0.0 Resolution: | Keywords: d.mon, d.vect, d.rast, python, | script, bash CPU: x86-64 | Platform: All -------------------------+------------------------------------------------- Comment (by santipardo): '''PROVISIONAL WORKAROUND:''' I have found that if I open a second monitor after the first, the layers are shown: {{{ grass.run_command('d.mon', start="wx3", resolution = '2') grass.run_command('d.rast', map="M01relief", overwrite="true") grass.run_command('d.mon', start="wx0", resolution = '1') grass.run_command('d.rast', map="M01relief", overwrite="true") grass.run_command('d.mon', select="wx3") grass.run_command('d.redraw', verbose="true") }}} With this code, I get an empty "wx0" monitor, and a "wx3" monitor showing my layers. But I need that second 'ghost' monitor, which is not very elegant... Any help with this is welcome. -- Ticket URL: GRASS GIS From trac at osgeo.org Thu Apr 30 00:57:49 2015 From: trac at osgeo.org (GRASS GIS) Date: Thu, 30 Apr 2015 07:57:49 -0000 Subject: [GRASS-dev] [GRASS GIS] #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) In-Reply-To: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> References: <044.d19ab371621daff40ae4b5b015e4bc60@osgeo.org> Message-ID: <059.33a9f1a76d3d31144f1ba5e7d45cbf36@osgeo.org> #2665: d.* modules not working from python or bash scripts (GRASS 7.0, Linux / Windows7) -------------------------+------------------------------------------------- Reporter: santipardo | Owner: grass-dev@? Type: defect | Status: new Priority: minor | Milestone: 7.0.1 Component: Display | Version: 7.0.0 Resolution: | Keywords: d.mon, d.vect, d.rast, python, | script, bash CPU: x86-64 | Platform: All -------------------------+------------------------------------------------- Changes (by santipardo): * priority: normal => minor -- Ticket URL: GRASS GIS From p.vanbreugel at gmail.com Thu Apr 30 05:25:02 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Thu, 30 Apr 2015 14:25:02 +0200 Subject: [GRASS-dev] r.relief Message-ID: <55421F1E.2060802@gmail.com> Hi, When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an integer map. Is this intended behavior? Would it be possible to have r.relief convert the layer to double precision / float automatically if the DEM is of CELL type? Paulo From hmitaso at ncsu.edu Thu Apr 30 06:15:34 2015 From: hmitaso at ncsu.edu (Helena Mitasova) Date: Thu, 30 Apr 2015 09:15:34 -0400 Subject: [GRASS-dev] r.relief In-Reply-To: <55421F1E.2060802@gmail.com> References: <55421F1E.2060802@gmail.com> Message-ID: <3AA4138D-F859-4090-BF23-CC568F62D426@ncsu.edu> I think that user should do the conversion (in most cases it needs to be reinterpolated). I think that the current behavior is right for many reasons, Helena > On Apr 30, 2015, at 8:25 AM, Paulo van Breugel wrote: > > Hi, > > When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an integer map. Is this intended behavior? Would it be possible to have r.relief convert the layer to double precision / float automatically if the DEM is of CELL type? > > Paulo > _______________________________________________ > grass-dev mailing list > grass-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev Helena Mitasova Professor at the Department of Marine, Earth, and Atmospheric Sciences and Center for Geospatial Analytics North Carolina State University Raleigh, NC 27695-8208 hmitaso at ncsu.edu http://geospatial.ncsu.edu/osgeorel/ "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.? From neteler at osgeo.org Thu Apr 30 06:53:31 2015 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 30 Apr 2015 15:53:31 +0200 Subject: [GRASS-dev] r.relief In-Reply-To: <55421F1E.2060802@gmail.com> References: <55421F1E.2060802@gmail.com> Message-ID: On Thu, Apr 30, 2015 at 2:25 PM, Paulo van Breugel wrote: > Hi, > > When running r.relief (in GRASS7.1) on a integer DEM raster, the output is > an integer map. Is this intended behavior? It appears to be hardcoded: raster/r.relief/main.c int out_type = CELL_TYPE; ... but then it casts the input to DCELL for the calculation: ... /* open the elevation file for reading */ in_fd = Rast_open_old(elev_name, ""); elev_cell[0] = (DCELL *) G_calloc(ncols + 1, sizeof(DCELL)); Rast_set_d_null_value(elev_cell[0], ncols); elev_cell[1] = (DCELL *) G_calloc(ncols, sizeof(DCELL)); Rast_set_d_null_value(elev_cell[1], ncols); elev_cell[2] = (DCELL *) G_calloc(ncols, sizeof(DCELL)); Rast_set_d_null_value(elev_cell[2], ncols); out_fd = Rast_open_new(sr_name, out_type); out_rast = Rast_allocate_buf(out_type); Rast_set_null_value(out_rast, Rast_window_cols(), out_type); Rast_put_row(out_fd, out_rast, out_type); out_size = Rast_cell_size(out_type); ... > Would it be possible to have > r.relief convert the layer to double precision / float automatically if the > DEM is of CELL type? Technically yes using Rast_get_map_type() http://grass.osgeo.org/programming7/raster_2open_8c.html#a535b2939a9d3869ce09e7fc45c649929 but I wonder what the rationale was to define CELL_TYPE? Maybe Markus M knows. markusN From p.vanbreugel at gmail.com Thu Apr 30 07:00:55 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Thu, 30 Apr 2015 16:00:55 +0200 Subject: [GRASS-dev] r.relief In-Reply-To: <3AA4138D-F859-4090-BF23-CC568F62D426@ncsu.edu> References: <55421F1E.2060802@gmail.com> <3AA4138D-F859-4090-BF23-CC568F62D426@ncsu.edu> Message-ID: <55423597.8070505@gmail.com> Out of curiosity, what are those reasons? From a user perspective it might not be that obvious (well, it wasn't for me at least). If the current implementation is maintained, perhaps it would be useful to add a note to the manual page? Paulo On 30-04-15 15:15, Helena Mitasova wrote: > I think that user should do the conversion (in most cases it needs to be reinterpolated). > I think that the current behavior is right for many reasons, > > Helena > > >> On Apr 30, 2015, at 8:25 AM, Paulo van Breugel wrote: >> >> Hi, >> >> When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an integer map. Is this intended behavior? Would it be possible to have r.relief convert the layer to double precision / float automatically if the DEM is of CELL type? >> >> Paulo >> _______________________________________________ >> grass-dev mailing list >> grass-dev at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev > Helena Mitasova > Professor at the Department of Marine, > Earth, and Atmospheric Sciences > and Center for Geospatial Analytics > North Carolina State University > Raleigh, NC 27695-8208 > hmitaso at ncsu.edu > http://geospatial.ncsu.edu/osgeorel/ > "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.? > From hmitaso at ncsu.edu Thu Apr 30 07:44:48 2015 From: hmitaso at ncsu.edu (Helena Mitasova) Date: Thu, 30 Apr 2015 10:44:48 -0400 Subject: [GRASS-dev] r.relief In-Reply-To: <55423597.8070505@gmail.com> References: <55421F1E.2060802@gmail.com> <3AA4138D-F859-4090-BF23-CC568F62D426@ncsu.edu> <55423597.8070505@gmail.com> Message-ID: <5B6DDE3A-E0D6-4421-B408-80B4B550625B@ncsu.edu> In areas of low relief the integer DEMs have steps (you get alternating flat and steep areas, with steep areas along contours which you may be seeing in your shaded relief map), so when you run r.relief and you get a nice smooth map because the data were converted to float using bilinear interpolation you do not realize that you have the steps (you don?t see them on the 2D elevation map). Then you run some modeling or analysis using slope or flow routing running through these flats (which could be quite large) and you get various artificial patterns of the modeling results in these flat areas or you run some statistical analysis you will get serious bias in the histogram see the slide #14 here http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ltopoanal.ppt If you convert to float using nearest neighbor you may still get the flats depending on the resolution. Integer DEMs are pretty much a pain to work with if you are doing more than just visualizing the terrain and the steps along 1m contours are quite hard to get rid of in areas of low relief - you pretty much have to reinterpolate the DEM. Integer shaded relief output alerts user that the data are integer and they may have a problem, or if it is in mountains that the integers are not an issue. So what may be a convenience for one user may cause problems for other users, so if we want to conversion it should be a flag (similar situation like the -a flag in r.watershed). Helena > On Apr 30, 2015, at 10:00 AM, Paulo van Breugel wrote: > > Out of curiosity, what are those reasons? From a user perspective it might not be that obvious (well, it wasn't for me at least). If the current implementation is maintained, perhaps it would be useful to add a note to the manual page? > > Paulo > > > > On 30-04-15 15:15, Helena Mitasova wrote: >> I think that user should do the conversion (in most cases it needs to be reinterpolated). >> I think that the current behavior is right for many reasons, >> >> Helena >> >> >>> On Apr 30, 2015, at 8:25 AM, Paulo van Breugel wrote: >>> >>> Hi, >>> >>> When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an integer map. Is this intended behavior? Would it be possible to have r.relief convert the layer to double precision / float automatically if the DEM is of CELL type? >>> >>> Paulo >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >> Helena Mitasova >> Professor at the Department of Marine, >> Earth, and Atmospheric Sciences >> and Center for Geospatial Analytics >> North Carolina State University >> Raleigh, NC 27695-8208 >> hmitaso at ncsu.edu >> http://geospatial.ncsu.edu/osgeorel/ >> "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.? >> > Helena Mitasova Professor at the Department of Marine, Earth, and Atmospheric Sciences and Center for Geospatial Analytics North Carolina State University Raleigh, NC 27695-8208 hmitaso at ncsu.edu http://geospatial.ncsu.edu/osgeorel/ "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.? From p.vanbreugel at gmail.com Thu Apr 30 09:08:03 2015 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Thu, 30 Apr 2015 18:08:03 +0200 Subject: [GRASS-dev] r.relief In-Reply-To: <5B6DDE3A-E0D6-4421-B408-80B4B550625B@ncsu.edu> References: <55421F1E.2060802@gmail.com> <3AA4138D-F859-4090-BF23-CC568F62D426@ncsu.edu> <55423597.8070505@gmail.com> <5B6DDE3A-E0D6-4421-B408-80B4B550625B@ncsu.edu> Message-ID: <55425363.6050805@gmail.com> Thanks for the explanation, and yes, it does makes sense to leave it as an option to the user. Rgds, Paulo On 30-04-15 16:44, Helena Mitasova wrote: > In areas of low relief the integer DEMs have steps (you get alternating flat and steep areas, with steep > areas along contours which you may be seeing in your shaded relief map), so when you run > r.relief and you get a nice smooth map because the data were converted to float using bilinear interpolation > you do not realize that you have the steps (you don?t see them on the 2D elevation map). > Then you run some modeling or analysis using slope or flow routing running through these flats (which could be quite large) and you get various artificial patterns of the modeling results in these flat areas or you run some statistical analysis you will get serious bias in the histogram > see the slide #14 here > http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ltopoanal.ppt > > If you convert to float using nearest neighbor you may still get the flats depending on the resolution. > Integer DEMs are pretty much a pain to work with if you are doing more than just visualizing > the terrain and the steps along 1m contours > are quite hard to get rid of in areas of low relief - you pretty much have to reinterpolate the DEM. > Integer shaded relief output alerts user that the data are integer and they may have a problem, > or if it is in mountains that the integers are not an issue. > > So what may be a convenience for one user may cause problems for other users, so if we want to conversion it should be a flag (similar situation like the -a flag in r.watershed). > > Helena > > > >> On Apr 30, 2015, at 10:00 AM, Paulo van Breugel wrote: >> >> Out of curiosity, what are those reasons? From a user perspective it might not be that obvious (well, it wasn't for me at least). If the current implementation is maintained, perhaps it would be useful to add a note to the manual page? >> >> Paulo >> >> >> >> On 30-04-15 15:15, Helena Mitasova wrote: >>> I think that user should do the conversion (in most cases it needs to be reinterpolated). >>> I think that the current behavior is right for many reasons, >>> >>> Helena >>> >>> >>>> On Apr 30, 2015, at 8:25 AM, Paulo van Breugel wrote: >>>> >>>> Hi, >>>> >>>> When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an integer map. Is this intended behavior? Would it be possible to have r.relief convert the layer to double precision / float automatically if the DEM is of CELL type? >>>> >>>> Paulo >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev at lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>> Helena Mitasova >>> Professor at the Department of Marine, >>> Earth, and Atmospheric Sciences >>> and Center for Geospatial Analytics >>> North Carolina State University >>> Raleigh, NC 27695-8208 >>> hmitaso at ncsu.edu >>> http://geospatial.ncsu.edu/osgeorel/ >>> "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.? >>> > Helena Mitasova > Professor at the Department of Marine, > Earth, and Atmospheric Sciences > and Center for Geospatial Analytics > North Carolina State University > Raleigh, NC 27695-8208 > hmitaso at ncsu.edu > http://geospatial.ncsu.edu/osgeorel/ > "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.? > From wenzeslaus at gmail.com Thu Apr 30 20:24:50 2015 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Thu, 30 Apr 2015 23:24:50 -0400 Subject: [GRASS-dev] Rendering from command line does not respect size Message-ID: Hi, I was trying to render some maps automatically but I'm having problems with setting the size of the image. I set size like this: export GRASS_RENDER_HEIGHT=1350 export GRASS_RENDER_WIDTH=1500 But with cairo I get still the default size: d.mon cairo d.rast aspect # map.png size is now 640x480 d.mon stop=cairo rm map.png With png I get an error: d.mon png d.rast aspect ERROR: PNG: input file has incorrect dimensions: expected: 640x480 got: 1500x1350 # map.png is now empty but it has the correct size d.mon stop=png rm map.png With wx0 I get the error but also an image in GUI. The main GUI works without any errors. I observe same behavior in 70 branch and when using height and width parameters of d.mon. I exited the session and started again. Any idea what's happening or what should I try? Thanks, Vaclav -------------- next part -------------- An HTML attachment was scrubbed... URL: