Re: [GRASS-dev] the function of v.buffer `minordistance' option
On 03/06/14 19:59, Maciej Sieczka wrote: Hi, Anybody knows what is the v.buffer's `minordistance' option supposed to do? The manual is not verbose about that, but as I understand it, together with `distance', it should allow to create a buffer with different extent along the minor and major axis, considering the specified `angle' of their rotation. But none of the options works as that - the buffer size always equals the `distance', and the other 2 options make no difference if used or not an set to what. BTW, it seems that -s, -c flags also don't have any effect on the output. Did I get it wrong or maybe there's something broken? In NC dataset: v.buffer schools_wake out=testbuf distance=500 minordistance=250 gives me the attached buffers. Everything seems to work fine here... Could you be more specific about what exactly is not working for you ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1628: segfault in r.walk
#1628: segfault in r.walk +--- Reporter: pertusus| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Raster | Version: svn-releasebranch64 Keywords: r.cost, r.walk |Platform: Linux Cpu: x86-64 | +--- Comment(by mlennert): Replying to [comment:8 mmetz]: Replying to [comment:7 mlennert]: Replying to [comment:5 glynn]: Replying to [comment:3 mlennert]: I do not have the time right now to check if this is linked to a specific attribute or just the general number of attributes, but maybe someone else can continue on that path ? Could it be a problem with lib/sites? It would seem a likely candidate, but how would that influence what is happening a long time after the closure of the input file ? The segfault occurs in the routine finding the cost path in which, AFAICT, the lib/sites doesn't play a role anymore. This can happen if the sites lib corrupts some memory that is not used by the sites lib itself. The segmentation fault can then appear anywhere else later on. You need to use valgrind to check memory usage and search for something like invalid [read|write] ... in the valgrind output, usually rather at the beginning than at the end of the valgrind output. I won't be able to work on this before next week, so if someone else wants to try... Apart from that, the usage of the wrappers provided by the sites lib is deprecated also in G6. I would suggest the replace the relevant code in the affected modules rather than fixing the sites lib. This sounds fairly invasive. Is this still feasible for 6.4.4 ? Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/1628#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
[GRASS-dev] Standard options label vs description
Hi, The Option and Flag structures have label and description. If label is missing, description is used as the main description. Otherwise, label becomes the main description and description becomes an indented explanation. When we want to add examples or explanations to some standard options, we have to assign both label and description even if the standard description is enough as label because those standard options only have description. We cannot simply assign description in this case. Some other standard options have both label and description, so it's not clear when to assign description only and when to assign both label and description. Also, it takes additional effort to copy the standard description to the label. IMHO, we have to always use the label for the first description and the description for additional examples or clarifications. This way, when the developer wants to override or add more details, s/he can simply assign description if s/he wants to use the standard label. Maybe forcing to use the label (G_fatal_error on an empty label) can be too much and break backward compatibility. I propose to change description to label for description-only standard options. E.g., G_OPT_DB_TABLE, G_OPT_F_INPUT, ... This proposed change shouldn't affect existing modules, but will ease writing new ones. I'm not sure about --interface/html-description. For now, it's mixed with label description. Some options have label and description, and others only have description. It looks like label is not required and g.gui can handle both cases. One problem with this mixed approach is that we cannot simply extract labels only to collect the main option descriptions. We have to parse the output and determine when to use label and when to use description for the main description. Standardizing the use of label and description will also help in this regard. Thanks. Huidae ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-03 9:10 GMT+02:00 Pietro peter.z...@gmail.com: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? I am waiting for reasonable/acceptable explanation for long time, I do not assume that it will ever come. Anyway, dear all, this commit completely broke the whole winGRASS 7.1 which even doesn't start File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 981, in gisenv s = read_command(g.gisenv, flags='n') File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 400, in read_command ps = pipe_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 375, in pipe_command return start_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 334, in start_command return Popen(args, **popts) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__ errread, errwrite) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in _execute_chil d startupinfo) WindowsError: [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor Error in GUI startup. If necessary, please report this error to the GRASS develo pers. Switching to text mode now. Hit RETURN to continue... Happily we have 7.0 which still includes this magic (in other words GRASS starts and works). Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Martin Landa wrote 2014-06-03 9:10 GMT+02:00 Pietro lt; peter.zamb@ gt;: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? I am waiting for reasonable/acceptable explanation for long time, I do not assume that it will ever come. Anyway, dear all, this commit completely broke the whole winGRASS 7.1 which even doesn't start File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 981, in gisenv s = read_command(g.gisenv, flags='n') File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 400, in read_command ps = pipe_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 375, in pipe_command return start_command(*args, **kwargs) File C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\script\core.py, l ine 334, in start_command return Popen(args, **popts) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 711, in __init__ errread, errwrite) File C:\OSGEO4~1\apps\Python27\lib\subprocess.py, line 948, in _execute_chil d startupinfo) WindowsError: [Error 2] SystÚm nem¨×e nalÚzt uvedenř soubor Error in GUI startup. If necessary, please report this error to the GRASS develo pers. Switching to text mode now. Hit RETURN to continue... Happily we have 7.0 which still includes this magic (in other words GRASS starts and works). Martin -- I don't understand this uneeded break of winGRASS 7.1. anyway, I've intensely tested this magic quite a lot in the last 2 months in different win-boxes (vista, 7, 8) with a bunch of different python scripts. no problem so far. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5143645p5144069.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
Pietro wrote: Reminder for all Windows users, please note that winGRASS 7.1 no.981 will be broken (calling python script from python script issue - eg. wxGUI Extension manager) again. 2014-06-03 7:24 GMT+02:00 svn_gr...@osgeo.org: Author: glynn Date: 2014-06-02 22:24:32 -0700 (Mon, 02 Jun 2014) New Revision: 60679 Modified: grass/trunk/lib/python/script/core.py Log: Remove Popen() magic on Windows; it creates more problems than it solves Please, could you explain which problems creates? The shell doesn't simply pass its arguments to the program being executed; it may interpret them (e.g. performing redirection in the presence of |, or characters). For a specific example of why this is a problem, see ticket #2314. http://trac.osgeo.org/grass/ticket/2314 The quoting performed by the subprocess module (specifically, the list2cmdline() function) doesn't take this into account (i.e. it doesn't perform any additional quoting when shell=True). So either: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. 2. If we know that the program is a script, the interpreter can be specified explicitly (i.e. python path/to/script.py). This keeps the shell out of the picture. -- 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] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste
Hi, 2014-06-04 19:17 GMT+02:00 svn_gr...@osgeo.org: 1. Consolite option/flag mutually exslusive messages. it would be nice to solve it in the parser level... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raste
I was thinking about the same thing. Maybe add char *exclusive_group to Option and Flag and G_parser() takes care of exclusiveness? On Wed, Jun 4, 2014 at 2:03 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014-06-04 19:17 GMT+02:00 svn_gr...@osgeo.org: 1. Consolite option/flag mutually exslusive messages. it would be nice to solve it in the parser level... Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ 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] the function of v.buffer `minordistance' option
W dniu 04.06.2014 14:53, Moritz Lennert pisze: On 03/06/14 19:59, Maciej Sieczka wrote: Anybody knows what is the v.buffer's `minordistance' option supposed to do? The manual is not verbose about that, but as I understand it, together with `distance', it should allow to create a buffer with different extent along the minor and major axis, considering the specified `angle' of their rotation. But none of the options works as that - the buffer size always equals the `distance', and the other 2 options make no difference if used or not an set to what. BTW, it seems that -s, -c flags also don't have any effect on the output. Did I get it wrong or maybe there's something broken? In NC dataset: v.buffer schools_wake out=testbuf distance=500 minordistance=250 gives me the attached buffers. Everything seems to work fine here... Could you be more specific about what exactly is not working for you ? Right, looks fine for points input. Not so for areas input though, e.g: $ v.buffer testbuf out=testbuf2 distance=500 minordistance=250 v.buffer in the latter case does not honor minordistance and uses distance for both axes, while I would expect it to behave the way it does for points input. Am I expecting something which is not implemented maybe? Maciek -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] the function of v.buffer `minordistance' option
On 04/06/14 20:42, Maciej Sieczka wrote: W dniu 04.06.2014 14:53, Moritz Lennert pisze: On 03/06/14 19:59, Maciej Sieczka wrote: Anybody knows what is the v.buffer's `minordistance' option supposed to do? The manual is not verbose about that, but as I understand it, together with `distance', it should allow to create a buffer with different extent along the minor and major axis, considering the specified `angle' of their rotation. But none of the options works as that - the buffer size always equals the `distance', and the other 2 options make no difference if used or not an set to what. BTW, it seems that -s, -c flags also don't have any effect on the output. Did I get it wrong or maybe there's something broken? In NC dataset: v.buffer schools_wake out=testbuf distance=500 minordistance=250 gives me the attached buffers. Everything seems to work fine here... Could you be more specific about what exactly is not working for you ? Right, looks fine for points input. Not so for areas input though, e.g: $ v.buffer testbuf out=testbuf2 distance=500 minordistance=250 v.buffer in the latter case does not honor minordistance and uses distance for both axes, while I would expect it to behave the way it does for points input. Am I expecting something which is not implemented maybe? For me this is more of a conceptual problem: how can you define a major and minor axis for buffers of polygons ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
On Wed, Jun 4, 2014 at 7:56 PM, Glynn Clements gl...@gclements.plus.com wrote: ... So either: 1. GRASS 7 will need .bat wrappers for Python scripts on Windows. That has the same issues as using shell=True, but at least it only applies in the case where we're executing a script. ... this would follow the apparently working method in GRASS 6. Maybe worth a try also in GRASS 7 at this point. 2. If we know that the program is a script, the interpreter can be specified explicitly (i.e. python path/to/script.py). This keeps the shell out of the picture. ... how much effort is the latter? Check file type and path to file? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] the function of v.buffer `minordistance' option
W dniu 04.06.2014 21:24, Moritz Lennert pisze: On 04/06/14 20:42, Maciej Sieczka wrote: W dniu 04.06.2014 14:53, Moritz Lennert pisze: On 03/06/14 19:59, Maciej Sieczka wrote: Anybody knows what is the v.buffer's `minordistance' option supposed to do? The manual is not verbose about that, but as I understand it, together with `distance', it should allow to create a buffer with different extent along the minor and major axis, considering the specified `angle' of their rotation. But none of the options works as that - the buffer size always equals the `distance', and the other 2 options make no difference if used or not an set to what. BTW, it seems that -s, -c flags also don't have any effect on the output. Did I get it wrong or maybe there's something broken? In NC dataset: v.buffer schools_wake out=testbuf distance=500 minordistance=250 gives me the attached buffers. Everything seems to work fine here... Could you be more specific about what exactly is not working for you ? Right, looks fine for points input. Not so for areas input though, e.g: $ v.buffer testbuf out=testbuf2 distance=500 minordistance=250 v.buffer in the latter case does not honor minordistance and uses distance for both axes, while I would expect it to behave the way it does for points input. Am I expecting something which is not implemented maybe? For me this is more of a conceptual problem: how can you define a major and minor axis for buffers of polygons ? Maybe they cross at the centroid, rotation angle applies? I was trying to make a minordistance=0.0111 distance=0.00697 vector area buffer in a latlon location. The northing/easting difference was supposed to copmpensate for the distance distortion, to some extent. But only then it came to me that it's better to reproject the input polygon to a metric location, create the regular fixed-distance buffer there, and reproject the buffer to the latlon location where I need it. Maciek -- Maciej Sieczka http://www.sieczka.org -- Maciej Sieczka http://www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60679 - grass/trunk/lib/python/script
2014-06-04 22:35 GMT+02:00 Markus Neteler nete...@osgeo.org:
2. If we know that the program is a script, the interpreter can be
specified explicitly (i.e. python path/to/script.py). This keeps the
shell out of the picture.
... how much effort is the latter? Check file type and path to file?
this check has been removed from thunk [1].
...
fcmd = get_real_command(args[0])
if fcmd.endswith('.py'):
Martin
[1]
http://trac.osgeo.org/grass/changeset/60679/grass/trunk/lib/python/script/core.py
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
