Re: [GRASS-dev] New: v.db.droprow
Hi, 2009/8/11 Markus Neteler nete...@osgeo.org: to be able to easily filter vector maps geometrically (i.e. remove vectors) I have written the v.db.droprow script (G6.5; needs a Python port for GRASS 7). Done in r38716. It removes vector objects (point, line, area, face etc.) from a vector map through attribute selection in the table. Also not sure if we need this script. In any case the name is probably misleading. Prefix 'v.db' indicates that the module modifies only attribute data, not geometry(?) I have some questions regarding Bash script: * are these extra checks needed (it's done by v.extract) [1,2] * unused variables [3] * G_OPT_OUTPUT instead of G_OPT_INPUT? [4] Thanks, Martin [1] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L86 [2] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L92 [3] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L97 [4] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L116 -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7
Soeren wrote: if there are no objections against the changes and the new LGPL'd ccmath library? I have no comment either way on the technical side of the library changes beyond wondering if it will peacefully interact with the (mostly unused) existing --with-blas --with-lapack ./configure switches. As for including a dependent library in GRASS I personally don't have a problem with that as it does not seem to be widely available or have much infrastructure of its own (beyond a e.g. Freshmeat.net writeup page*). i.e. not a fork because there isn't really any new version to keep in sync with, and users would have a hard time finding a package for it. As for including LGPL code in the main trunk I personally don't have a problem with that as it reflects the upstream license/author's wishes, is new code, and is used as a library. By my reading the RFC2 doc nor 'g.version -c' the COPYING file need any adjustment to cover this. But a formal decision on that may be a matter for the PSC. As long as everything in the lib/ccmath/ dir falls under the same (GPL compatible) license and the LGPL.txt file is placed in that dir I'd be happy. Hamish [*] a web search for ccmath found a most interesting auto-georegistration tool for applying/projecting a 3D registration onto 2D photographs: gipfel. Check out the .avi demo. http://io.debian.net/~tar/debian/gipfel/ Note the track overlay is from a x,y,z text file, very neat. reminds me a bit of i.points.auto, Stereo[1], and autopano-sift[2] software. [1] http://grass.osgeo.org/gdp/stereo-grass/index.html [2] http://user.cs.tu-berlin.de/~nowozin/autopano-sift/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
On Fri, Aug 14, 2009 at 10:15 AM, Martin Landalanda.mar...@gmail.com wrote: 2009/8/11 Markus Neteler nete...@osgeo.org: It removes vector objects (point, line, area, face etc.) from a vector map through attribute selection in the table. Also not sure if we need this script. How would you do vector removal based on attributes? In any case the name is probably misleading. Prefix 'v.db' indicates that the module modifies only attribute data, not geometry(?) Perhaps yes (I considered it a v.db.* since it uses the attribute table). I have some questions regarding Bash script: * are these extra checks needed (it's done by v.extract) [1,2] Yes, I think so: if you create a map with v.random it won't have a connected table, so better don't badly crash. Likewise with a non-existing map. I used existing msg strings (for translation). * unused variables [3] Removed. * G_OPT_OUTPUT instead of G_OPT_INPUT? [4] Right, fixed. Thanks, Martin [1] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L86 [2] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L92 [3] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L97 [4] http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/v.db.droprow/v.db.droprow#L116 thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] output of doubles as text
unanswered from trac bug #355, reproduced here to gain eyeballs. https://trac.osgeo.org/grass/ticket/335 (just 13 remaining RC bugs for 6.4.0: https://trac.osgeo.org/grass/report/13 ) i.e. can we always assume DCELL|double to be the same bit depth, and %.15g the most we'll ever be able to squeeze from it? perhaps that's poorly worded: not that DCELL == double, but that size(double) in one place == size(double) in another. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] trac #637: spaces in path names (wx + tcl)
Hi, re. stalled bug #637, https://trac.osgeo.org/grass/ticket/637#comment:11 I take it the wxGUI use of 'v.db.connect -g' still should explicitly set the fs='|' and split() on that instead of space? Also Tcl/Tk versions of same still need attention / testing / backporting: https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/gui/tcltk/gis.m https://trac.osgeo.org/grass/changeset/38295 https://trac.osgeo.org/grass/changeset/38296 https://trac.osgeo.org/grass/changeset/38426 https://trac.osgeo.org/grass/changeset/38427 and in general C code, https://trac.osgeo.org/grass/changeset/38436 ... maybe others thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.li
Platform: All| Cpu: All
+---
Comment (by pcav):
Right, sorry for not checking this. However, setting the right path does
not help:
{{{
Unable to open header file for raster map @(null)
CHILD[pid = 6809]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6808]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6807]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6806]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6805]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6804]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6803]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6802]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6801]: unable to open mask ... continue without!!!
Unable to open header file for raster map @(null)
CHILD[pid = 6800]: unable to open mask ... continue without!!!
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/718#comment:7
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #129: a fix for NVIZ site's dependency: elimination of sites lib dependency
#129: a fix for NVIZ site's dependency: elimination of sites lib dependency --+- Reporter: neteler | Owner: neteler Type: defect | Status: assigned Priority: major| Milestone: 6.4.0 Component: NVIZ | Version: svn-trunk Resolution: |Keywords: nviz Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): see r38604 -- Ticket URL: https://trac.osgeo.org/grass/ticket/129#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename +--- Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: 6.4.0 RCs Resolution: |Keywords: r.li Platform: All| Cpu: All +--- Comment (by neteler): Replying to [comment:7 pcav]: Right, sorry for not checking this. However, setting the right path does not help: As mentioned above, the path should NOT be set. conf= has to be a filename, not a full pathname. Please always post the command line to better illustrate the problem (also in GUI mode available) @devs: can we simply strip off the directory stuff? Markus -- Ticket URL: https://trac.osgeo.org/grass/ticket/718#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename +--- Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: 6.4.0 RCs Resolution: |Keywords: r.li Platform: All| Cpu: All +--- Comment (by pcav): r.li.shannon map=landclas...@permanent conf=landclass96_conf output=landclass96_shannon -- Ticket URL: https://trac.osgeo.org/grass/ticket/718#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
Hi, 2009/8/14 Markus Neteler nete...@osgeo.org: * are these extra checks needed (it's done by v.extract) [1,2] Yes, I think so: if you create a map with v.random it won't have a connected table, so better don't badly crash. Likewise with a non-existing map. I used existing msg strings (for translation). Badly crash? After r38718: $ v.db.droprow in=x out=x1 w='x' --o ERROR: Vector map x not found $ v.db.droprow in=p out=x1 w='x' --o ERROR: Database connection not defined for layer 1 It seems reasonable to me. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
Hi, 2009/8/14 Martin Landa landa.mar...@gmail.com: * are these extra checks needed (it's done by v.extract) [1,2] Yes, I think so: if you create a map with v.random it won't have a connected table, so better don't badly crash. Likewise with a non-existing map. I used existing msg strings (for translation). BTW, why are you requesting the input vector map from the current mapset? Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling today's grass7 trunk: ogr_srs_api.h: No such file or directory
Hi, 2009/8/6 Glynn Clements gl...@gclements.plus.com: The correct approach is to revert the portion of r38552 which applies to lib/gis/find_vect.c, lib/gis/find_file.c, and lib/gis/Makefile. lib/gis has no business calling OGR functions, or even linking against OGR. If it's impossible to find a vector without them, then find_vect.c should be removed altogether, and the functions moved into the vector library. right, I reverted changes in r38719. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.li
Platform: All| Cpu: All
+---
Comment (by hamish):
Just to clarify some points,
- the original command Paolo gave (copied in comment:1) is not to the
full path and the
{{{
WARNING: Unable to open header file for raster map @(null)
}}}
errors appear without the failure to stat config file. Apparently failure
to kill spawned workers on a fatal error is a coincidental bug.
- it is not just debian/sid 64 bit, William sees it too on Mac OSX 64bit.
- I don't see it on amd64 debain/lenny with a self-compiled 6.5svn. I
haven't tried the debian packages there.
- is there any MASK set or is that message just coming from no where?
H
--
Ticket URL: https://trac.osgeo.org/grass/ticket/718#comment:10
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
On 14/08/09 10:43, Markus Neteler wrote: On Fri, Aug 14, 2009 at 10:15 AM, Martin Landalanda.mar...@gmail.com wrote: 2009/8/11 Markus Neteler nete...@osgeo.org: It removes vector objects (point, line, area, face etc.) from a vector map through attribute selection in the table. Also not sure if we need this script. How would you do vector removal based on attributes? v.extract -r ... where= Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-windows] No such file or directory
(cc grass-dev) [r.in.poly fails to read text input file on Windows/CMD line] On Fri, Aug 14, 2009 at 3:52 PM, Peter Brookspe...@timedworld.com wrote: No, I think it is whitespace... I'm trying to use the 'cmd ' field in the 'GRASS GIS Layer Manager' (the new wxPython GUI). I guess this is what a Windows user would try to do :-) I tried adding a space to the folder name (= 'c:\nc external'), forward slashes don't help but speech or quote marks do. (I think the same thing happens with all r.in commands if they are looking for external files - is this to be expected?) Using the GRASS Command line utility (DOS shell type interface): GRASS 6.4.0svn (North-Carolina) cd c:/nc external The system cannot find the path specified. GRASS 6.4.0svn (North-Carolina) cd c:\nc external (works ok) @devs: Perhaps we need some more G_convert_dirseps_*() magic? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New: v.db.droprow
On Fri, Aug 14, 2009 at 3:30 PM, Moritz Lennertmlenn...@club.worldonline.be wrote: On 14/08/09 10:43, Markus Neteler wrote: On Fri, Aug 14, 2009 at 10:15 AM, Martin Landalanda.mar...@gmail.com wrote: 2009/8/11 Markus Neteler nete...@osgeo.org: It removes vector objects (point, line, area, face etc.) from a vector map through attribute selection in the table. Also not sure if we need this script. How would you do vector removal based on attributes? v.extract -r ... where= Ok, while I disagree that this is obvious (especially to newcomers), I'll remove the module now in 6.5. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-SVN] r38731 - grass/branches/develbranch_6/scripts
2009/8/14 svn_gr...@osgeo.org: Author: neteler Date: 2009-08-14 12:56:13 -0400 (Fri, 14 Aug 2009) New Revision: 38731 Removed: grass/branches/develbranch_6/scripts/v.db.droprow/ Log: v.db.droprow apparently undesired should be v.db.droprow also removed from trunk? Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.gshhs v2.0 error reading data
Hi, I've updated v.in.gshhs, it supports now GSHHS data versions 1.4 through to 2.0, and issues an error if a version is not supported, telling exactly that, no more non-descript error reading data. v.in.gshhs imports exported as shapefiles display now properly in QGIS, no more strange horizontal lines. Please check out the new version and let me know if it doesn't work for you. Markus M Jamie Adams wrote: I grabbed the 2.0 version of gshhs, released 2009-07-15, but can't import it into GRASS. The module doesn't return much in terms of error information. v.in.gshhs in=gshhs_f.b out=gshhs_f --o Using lat/lon bounds N=90.00 S=-90.00 E=180.00 W=-180.00 ERROR: Error reading data I've tried the various levels of detail (f, h, i, l) with the same result. Based on the readme file there may be some internal changes, but these are beyond me. Any thoughts? - Jamie GSHHS 2.0 - http://www.soest.hawaii.edu/pwessel/gshhs/index.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.gshhs v2.0 error reading data
That did the trick, thanks for the quick update! - Jamie On Fri, Aug 14, 2009 at 9:56 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Hi, I've updated v.in.gshhs, it supports now GSHHS data versions 1.4 through to 2.0, and issues an error if a version is not supported, telling exactly that, no more non-descript error reading data. v.in.gshhs imports exported as shapefiles display now properly in QGIS, no more strange horizontal lines. Please check out the new version and let me know if it doesn't work for you. Markus M Jamie Adams wrote: I grabbed the 2.0 version of gshhs, released 2009-07-15, but can't import it into GRASS. The module doesn't return much in terms of error information. v.in.gshhs in=gshhs_f.b out=gshhs_f --o Using lat/lon bounds N=90.00 S=-90.00 E=180.00 W=-180.00 ERROR: Error reading data I've tried the various levels of detail (f, h, i, l) with the same result. Based on the readme file there may be some internal changes, but these are beyond me. Any thoughts? - Jamie GSHHS 2.0 - http://www.soest.hawaii.edu/pwessel/gshhs/index.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-windows] No such file or directory
[r.in.poly fails to read text input file on Windows/CMD line] I have checked at the r.in.poly source code, the problem does not seem to be there. The path is passed to fopen() verbatim. what version/revision of 6.4.0svn is this? is it the latest? ISTR that MartinGlynn had fixed this -- wxGUI now uses a python parser which understands shell quoting on the Cmd line. But that might only be present in the very latest build. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-windows] No such file or directory
Peter Brooks wrote: No, I think it is whitespace... I'm trying to use the 'cmd ' field in the 'GRASS GIS Layer Manager' (the new wxPython GUI). I guess this is what a Windows user would try to do :-) I tried adding a space to the folder name (= 'c:\nc external'), forward slashes don't help but speech or quote marks do. (I think the same thing happens with all r.in commands if they are looking for external files - is this to be expected?) If an option expects a filename, it will typically be passed directly to open(), fopen() etc. If you supply a plain filename or a relative path, it will be interpreted relative to the current directory (rather than e.g. the mapset directory). If an option value contains whitespace, it needs to be quoted appropriately for the context in which it occurs. In a Windows command prompt, you need to put double quotes around the entire option=value argument. In bash, you can use single or double quotes around the entire argument or around the filename, or precede spaces by backslash characters (also, you need to either use forward slashes as directory separators or quote backslashes appropriately). The command prompt in the wxPython GUI uses Python's shlex module (in POSIX mode), which provides bash-like quoting: http://docs.python.org/library/shlex.html#parsing-rules Filenames entered elsewhere in the GUI shouldn't normally need to be quoted. Even with correct quoting, some shell scripts may not correctly handle filenames containing spaces; this is part of the reason why shell scripts have been replaced with Python scripts in GRASS 7. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath/gpde Patch for grass6.5 and grass7
Hamish wrote: As for including LGPL code in the main trunk I personally don't have a problem with that as it reflects the upstream license/author's wishes, is new code, and is used as a library. By my reading the RFC2 doc nor 'g.version -c' the COPYING file need any adjustment to cover this. But a formal decision on that may be a matter for the PSC. As long as everything in the lib/ccmath/ dir falls under the same (GPL compatible) license and the LGPL.txt file is placed in that dir I'd be happy. If it's being included in the main GRASS tree, it would be simpler to relicense it as GPL. The main thing is to ensure that each file has a header stating that it is licensed under the LGPL. In the absence of such a header, we can't reasonably assume that any additions to the code are licensed under the LGPL. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] output of doubles as text
Hamish wrote: i.e. can we always assume DCELL|double to be the same bit depth, and %.15g the most we'll ever be able to squeeze from it? perhaps that's poorly worded: not that DCELL == double, but that size(double) in one place == size(double) in another. We can assume that it always refers to IEEE 754 double precision format. Systems where this isn't the case are extremely uncommon, and will almost certainly fail to support GRASS without a great deal of additional effort. And regardless of the precision of double, I seriously doubt that anyone has actual data which is accurate to 15 significant digits (equivalent to specifying the circumference of the earth to within 40 nanometres, or the height of Everest to within 9 picometres). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] trac #637: spaces in path names (wx + tcl)
Hamish wrote: I take it the wxGUI use of 'v.db.connect -g' still should explicitly set the fs='|' and split() on that instead of space? Yes. Also Tcl/Tk versions of same still need attention / testing / backporting: https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/gui/tcltk/gis.m https://trac.osgeo.org/grass/changeset/38295 https://trac.osgeo.org/grass/changeset/38296 https://trac.osgeo.org/grass/changeset/38426 https://trac.osgeo.org/grass/changeset/38427 and in general C code, https://trac.osgeo.org/grass/changeset/38436 The dbmscap fix is in the wrong place. Any quoting should be done within db_start_driver() (and the Unix version shouldn't be using the shell; there's no need for it). More generally, most of those quoting fixes are bogus. The solution is to use G_spawn() rather than using the shell. Using the shell is a bug; quoting is just a workaround. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename +--- Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Raster | Version: 6.4.0 RCs Resolution: |Keywords: r.li Platform: All| Cpu: All +--- Comment (by glynn): Replying to [comment:8 neteler]: As mentioned above, the path should NOT be set. conf= has to be a filename, not a full pathname. Please always post the command line to better illustrate the problem (also in GUI mode available) @devs: can we simply strip off the directory stuff? It would be better to only prepend ~/.r.li/ if the filename isn't an absolute path (see G_is_absolute_path()), or possibly if it doesn't contain any directory separators. AFAIK, the GUI will see old_file in the -gisprompt field and provide an absolute pathname. Either the -gisprompt field needs to be removed (so it's just a string option), or the code needs to be changed to allow an absolute pathname. Or it could enumerate ~/.r.li/ and add all files found therein to the -options field. Certainly, it shouldn't silently discard any directory components; that would leave the user trying to figure out why it isn't behaving as expected. -- Ticket URL: https://trac.osgeo.org/grass/ticket/718#comment:12 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename
#718: r.li forgets mask/illegal filename
+---
Reporter: kyngchaos | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.li
Platform: All| Cpu: All
+---
Comment (by glynn):
Replying to [comment:11 hamish]:
One thing it may be, that I haven't tried is if GRASS is built without
the gcc -g debugging flag. I always build with that and AFAIU that means
all variables are initizalied to '\0' (null).
No. Static variables (global variables and local variables with the
static qualifier) without an explicit initialiser are implicitly
initialised to zero regardless of the compiler options used. This
behaviour is mandated by the C standards. A static variable's initial
value is stored in the binary, so it isn't possible for a static variable
to be uninitialised.
[However, variables which are initialised to zero, explicitly or
implicitly, are all stored in the BSS segment. As the entire segment
contains only zeros, it can be compressed to nothing. Nonetheless,
everything within that segment is initialised to zero at startup.]
Automatic variables (local variables lacking the static qualifier)
without an explicit initialiser are normally uninitialised; I have seen
compilers which will initialise such variables (not necessarily to zero)
in debug mode, but I've never seen gcc do it (gcc's -g switch controls
whether or not debug info is added to the output file; it doesn't affect
code generation in any way, unlike e.g. MSVC where debug mode disables
optimisation by default).
Also, enabling or disabling optimisations may affect what happens to be
stored in a particular section of uninitialised memory, even if it doesn't
affect whether or not initialisation occurs.
However:
If there is a test that some empty variable == NULL, such as
r.li.daemon/worker.c's {{{ if (ad-mask_name == NULL) { }}}, and that
variable is not explicitly made empty upon creation and then used
uninitialized well, it's a theory.
ad is a pointer to a structure which is allocated with G_malloc(). This
uses malloc, which doesn't normally initialise memory (although, again,
some implementations will initialise malloc()d memory in debug mode, but
not usually to zero).
--
Ticket URL: https://trac.osgeo.org/grass/ticket/718#comment:13
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wingrass and ArcGIS with Python
For those who need to run both ArcGIS and GRASS with Python (common situation in GIS labs), here is the solution for the reported problem from our technical support: I found there are different builds of winpython 2.5 . The version that works for both is build is 212. I found it here... http://sourceforge.net/projects/pywin32/files/pywin32/Build%20212/ pywin32-212.win32-py2.5.exe/download Helena Message: 1 Date: Thu, 6 Aug 2009 21:44:23 -0400 From: Helena Mitasova hmit...@unity.ncsu.edu Subject: [GRASS-windows] Re: [GRASS-dev] wingrass on VISSTA and XP with twopythons To: grass-wind...@lists.osgeo.org Cc: GRASS developers list grass-dev@lists.osgeo.org Message-ID: e0d9abbf-4109-46f0-a0c7-0c7f93615...@unity.ncsu.edu Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Just an update, in case somebody else has a similar problem - GRASS from OSGeo4W installer runs with nviz on the same VISTA computers that had the problem below. But we got an interesting issue with the native installer on our XP machines in the teaching lab. After a separate Python2.5 install GRASS wxpython does not run anymore The error message says: python.exe the procedure entry point ? PyWinObject_AsHABDLE@@YAHPAU_object@@pa...@z could not be located in the dynamic link library pywintypes25.dll when we searched for pywintypes25.dll we got C:\GRASS6-6-SVN\extralib 112KB 1/11/2009 C:\WINDOWS\system32 100KB 9/22/2006 C:\Python25\Lib\site_packages\ 100KB 9/22/2006 C:\GRASS6-6-SVN\Python25\Lib 112KB 1/11/2009 so it looks like the C:\Python25\Lib\site_packages version is different from the one used by GRASS I asssume that the problem we have is that GRASS is looking into the wrong pywintypes25.dll. Is there a solution to this? So far it looks like removing the second install of Python2.5 is not an option. thanks, Helena On Aug 6, 2009, at 11:02 AM, Helena Mitasova wrote: Has anybody installed the latest install on VISSTA? we get only the first two icons and no Tcltk runs (that means no nviz) http://grass.osgeo.org/grass64/binary/mswindows/native/ WinGRASS-6.4.0SVN-r38537-1-Setup.exe thanks, Helena___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- ___ grass-windows mailing list grass-wind...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-windows End of grass-windows Digest, Vol 36, Issue 2 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
