Re: [GRASS-dev] [GRASS GIS] #2419: v.distance: hole considered as nearest area
#2419: v.distance: hole considered as nearest area
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 6.4.5
Component: Vector| Version: svn-releasebranch64
Keywords: v.distance holes |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by mmetz):
Replying to [ticket:2419 mlennert]:
The following command line in the NC dataset:
{{{
v.distance -p from=comm_colleges to=urbanarea upload=cat,dist
col=to_cat,dist dmin=0.0001
}}}
leads to two points (from_cats 15 and 52) to have a hole as nearest
area, leading to to_cat=null. The closest areas should be areas (in grass7
the found to_cats are respectively 54 and 35).
Fixed in r61987,8.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2419#comment:1
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] [GRASS GIS] #2420: WinGRASS 7.1 download / website
#2420: WinGRASS 7.1 download / website -+-- Reporter: jbrauner | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: Website Component: Website | Version: unspecified Keywords: wingrass, download, website |Platform: Unspecified Cpu: Unspecified | -+-- Hi devs, it's currently inconsistent to find the winGRASS downloads for GRASS 7.1. It's not listed on tab Download - Software - MS-Windows [1] and can only be found when click on Download - Software [2] where the whole software matrix can be found. (Was it me who constantly downloaded new versions of the beta releases instead of the latest trunk build - hmmm :D ?) Anyhow, I thought about providing HTML for that but since it's a CMS I don't think it would be of much use (btw. there are some artifact links to GRASS 6.4 in the HTML code for the GRASS 7 table cells (neither visible nor clickable)). If I can help, let me know. Cheers, Johannes [1] http://grass.osgeo.org/download/software/ms-windows/ [2] http://grass.osgeo.org/download/software/ -- Ticket URL: http://trac.osgeo.org/grass/ticket/2420 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] G7: how to get rid of multiple listing of identical map names?
Markus Neteler wrote: OTOH, given that it fixes a fairly fundamental bug, it should go into at least one beta prior to any final release. So that would be r61840 + r61853 to be backported. But how to test it in trunk? Backport to beta, see if any issues show up. In terms of constructing test cases, you need a location where the ... was found in more mapsets warnings are common. As a rough guide: clone a mapset, place the clone ahead of the original in the mapset search path, remove various support files from the cloned maps, then run commands which try to use those support files, and check that they aren't finding the files from the original maps. -- 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 GIS] #2150: Cannot call Python scripts from Python on MS Windows
#2150: Cannot call Python scripts from Python on MS Windows ---+ Reporter: wenzeslaus | Owner: grass-dev@… Type: defect | Status: new Priority: blocker| Milestone: 7.0.0 Component: Python | Version: svn-releasebranch64 Keywords: packaging, MAXREPEAT, scripts |Platform: MSWindows 7 Cpu: Unspecified| ---+ Comment(by glynn): Replying to [comment:19 annakrat]: Glynn, what about r60870? Should it be backported? Yes. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2150#comment:21 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] [GRASS GIS] #2150: Cannot call Python scripts from Python on MS Windows
#2150: Cannot call Python scripts from Python on MS Windows ---+ Reporter: wenzeslaus | Owner: grass-dev@… Type: defect | Status: new Priority: blocker| Milestone: 7.0.0 Component: Python | Version: svn-releasebranch64 Keywords: packaging, MAXREPEAT, scripts |Platform: MSWindows 7 Cpu: Unspecified| ---+ Comment(by martinl): Replying to [comment:21 glynn]: Replying to [comment:19 annakrat]: Glynn, what about r60870? Should it be backported? Yes. done in r61992. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2150#comment:22 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] [GRASS GIS] #2418: t.unregister: maps-parameter limited to ca. 5000 maps
#2418: t.unregister: maps-parameter limited to ca. 5000 maps -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Temporal | Version: unspecified Keywords: |Platform: Linux Cpu: Unspecified | -+-- Comment(by huhabla): Replying to [ticket:2418 sbl]: In t.unregister the maps parameter seems to be limited to ca. 5000 maps. I have a strds with ca. 20k raster maps and tried to remove all by piping the output from t.rast.list to the maps parameter in t.unregister. After some testing I found out that the maps parameter works fine with 5000 maps, but with 6000 maps and more I got an Argument list to long error. This is not a defect, its the os specific limitation of argument lists[1]. However, unregistering of all 20k maps worked fine when output from t.rast.list was stored in a file and then t.unregister`s file parameter used. The reason for the input file option is the os limit of command line arguments. So you did exactly the right thing by using it in case of 20k maps. BTW, maybe a flag for unregistering all maps in a stds would be useful? Sounds useful indeed, feel free to add it to t.unregister. :) [1] https://wiki.debian.org/CommonErrorMessages/ArgumentListTooLong -- Ticket URL: https://trac.osgeo.org/grass/ticket/2418#comment:1 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] vector display clipping
Anna Petrášová wrote: can anyone explain the difference between grass64 and 7 in clipping vector data for display? I attached 2 pictures created with d.mon png and cairo driver Which is png and which is cairo? (to avoid influences from GUI) and you can see that in 64 the lines are clipped to match computational region while in grass7 it seems to display all vector features which have at least part in the region. Is this bug or feature? I couldn't find any discussion on this topic... In 7.0, there are two distinct sets of clipping operations. D_set_clip_mode, D_set_clip and D_clip_to_map control clipping which is performed within the display library. The default is no clipping. Using this functionality for graphical clipping is problematic if you use thick lines, as clipped lines will be capped at the point where they're clipped. It would also affect the dash offset for dashed lines (although that isn't implemented yet). Additionally, the driver's Set_window function establishes a clip region (e.g. via cairo_clip() for the cairo driver). This defaults to the entire screen, but can be overridden by setting the environment variable GRASS_FRAME. Arguably, the code which sets up the coordinate system so that the current region just fits the display (D_setup) should also set the clip region to fit the current region. However, this is complicated slightly be the fact that there's no distinction between the display frame (either the screen or the frame set by GRASS_FRAME) and the current clip region, so setting a clip region would lose the only record of the frame. -- 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
Huidae Cho wrote: We also need to add option_rules or something to g.parser so that python scripts can have access to these functions. Something like: #%option_rules #% exclusive: -a, -b #% requires_all: opt1, opt2, -a #%end Done in r61994. -- 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] G7: how to get rid of multiple listing of identical map names?
On Tue, Sep 16, 2014 at 12:41 PM, Glynn Clements gl...@gclements.plus.com wrote: Markus Neteler wrote: OTOH, given that it fixes a fairly fundamental bug, it should go into at least one beta prior to any final release. So that would be r61840 + r61853 to be backported. But how to test it in trunk? Backport to beta, see if any issues show up. Done in r61995 (relbr7). In terms of constructing test cases, you need a location where the ... was found in more mapsets warnings are common. As a rough guide: clone a mapset, place the clone ahead of the original in the mapset search path, remove various support files from the cloned maps, then run commands which try to use those support files, and check that they aren't finding the files from the original maps. Thanks - this should be done on various OS. Markus ___ 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
On Tue, Sep 16, 2014 at 8:07 AM, Glynn Clements gl...@gclements.plus.com wrote: Huidae Cho wrote: We also need to add option_rules or something to g.parser so that python scripts can have access to these functions. Something like: #%option_rules #% exclusive: -a, -b #% requires_all: opt1, opt2, -a #%end Done in r61994. Great, thanks! Now we (whoever it means) should try to document the new rules in the programming manual ( http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html). The parser syntax for Python scripts is not really documented anywhere, or am I missing something? Anna -- 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 mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] doxygen color style
Hi all, strangely when I compile Doxygen manual (`make htmldoc-single) locally it uses standard blue-like style, but on grass server [1] it's greeny. How is it possible? Thanks, Martin [1] http://grass.osgeo.org/programming7/ -- 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] [GRASS GIS] #2421: Functions from CDHC have no prefix
#2421: Functions from CDHC have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: cdhc, api|Platform: Unspecified
Cpu: Unspecified |
-+--
In contrast to other GRASS libs, CDHC lib (1) doesn't use by prefix. I
would suggest to change eg.
{{{
anderson_darling()
}}}
to
{{{
Cdhc_anderson_darling()
}}}
Any option? Marked as blocker since it's API change.
(1) http://grass.osgeo.org/programming7/cdhclib.html
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2421
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] [GRASS GIS] #2421: Functions from CDHC lib have no prefix
#2421: Functions from CDHC lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: cdhc, api|Platform: Unspecified
Cpu: Unspecified |
-+--
Description changed by martinl:
Old description:
In contrast to other GRASS libs, CDHC lib (1) doesn't use any prefix. I
would suggest to change eg.
{{{
anderson_darling()
}}}
to
{{{
Cdhc_anderson_darling()
}}}
Any option? Marked as blocker since it's API change.
(1) http://grass.osgeo.org/programming7/cdhclib.html
New description:
In contrast to other GRASS libs, CDHC lib (1) doesn't use any prefix. I
would suggest to change eg.
{{{
anderson_darling()
}}}
to
{{{
Cdhc_anderson_darling()
}}}
Any option? Marked as blocker since it's API change.
(1) http://grass.osgeo.org/programming7/cdhclib.html
--
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2421#comment:2
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] [GRASS GIS] #2421: Functions from CDHC lib have no prefix (was: Functions from CDHC have no prefix)
#2421: Functions from CDHC lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: cdhc, api|Platform: Unspecified
Cpu: Unspecified |
-+--
Description changed by martinl:
Old description:
In contrast to other GRASS libs, CDHC lib (1) doesn't use by prefix. I
would suggest to change eg.
{{{
anderson_darling()
}}}
to
{{{
Cdhc_anderson_darling()
}}}
Any option? Marked as blocker since it's API change.
(1) http://grass.osgeo.org/programming7/cdhclib.html
New description:
In contrast to other GRASS libs, CDHC lib (1) doesn't use any prefix. I
would suggest to change eg.
{{{
anderson_darling()
}}}
to
{{{
Cdhc_anderson_darling()
}}}
Any option? Marked as blocker since it's API change.
(1) http://grass.osgeo.org/programming7/cdhclib.html
--
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2421#comment:1
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] [GRASS GIS] #2421: Functions from CDHC lib have no prefix
#2421: Functions from CDHC lib have no prefix --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: cdhclib, api, prefix |Platform: Unspecified Cpu: Unspecified | --+- Changes (by martinl): * keywords: cdhc, api = cdhclib, api, prefix -- Ticket URL: http://trac.osgeo.org/grass/ticket/2421#comment:3 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] [GRASS GIS] #2422: Functions from Segment lib have no prefix
#2422: Functions from Segment lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibRaster| Version: unspecified
Keywords: segmentlib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by martinl):
Replying to [ticket:2422 martinl]:
{{{
Rast_segment_open()
}}}
Or
{{{
Segment_segment_open()
}}}
inspired by Row Input/Output Library,
http://grass.osgeo.org/programming7/rowiolib.html
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2422#comment:1
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] doxygen color style
On Tue, Sep 16, 2014 at 11:42 AM, Martin Landa landa.mar...@gmail.com wrote: Hi all, strangely when I compile Doxygen manual (`make htmldoc-single) locally it uses standard blue-like style, but on grass server [1] it's greeny. How is it possible? When I tested this at my computer it was green (`make htmldox`). Be sure to reload the page (several times), browser might want to trick you. Vaclav Thanks, Martin [1] http://grass.osgeo.org/programming7/ -- 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] [GRASS GIS] #2422: Functions from Segment lib have no prefix
#2422: Functions from Segment lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibRaster| Version: unspecified
Keywords: segmentlib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by martinl):
Replying to [comment:1 martinl]:
{{{
Segment_segment_open()
}}}
inspired by Row Input/Output Library,
http://grass.osgeo.org/programming7/rowiolib.html
I meant
{{{
Segment_open()
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2422#comment:2
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] [GRASS GIS] #2422: Functions from Segment lib have no prefix
#2422: Functions from Segment lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibRaster| Version: unspecified
Keywords: segmentlib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
-+--
In contrast to other GRASS libs, Segment lib (1) doesn't use any prefix. I
would suggest to change eg.
{{{
segment_open()
}}}
to
{{{
Rast_segment_open()
}}}
Any option? Marked as blocker since it's API change.
(1) http://grass.osgeo.org/programming7/segmentlib.html
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2422
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] [GRASS GIS] #2422: Functions from Segment lib have no prefix
#2422: Functions from Segment lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibRaster| Version: unspecified
Keywords: segmentlib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by martinl):
Replying to [comment:2 martinl]:
Replying to [comment:1 martinl]:
inspired by Row Input/Output Library,
http://grass.osgeo.org/programming7/rowiolib.html
from this point of view, we could rename function in this library to eg.
{{{
Rowio_get() - Rast_rowio_get()
}}}
and
{{{
segment_open() - Rast_segment_open()
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2422#comment:3
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] vector display clipping
Hi, thanks for reply, On Tue, Sep 16, 2014 at 7:59 AM, Glynn Clements gl...@gclements.plus.com wrote: Anna Petrášová wrote: can anyone explain the difference between grass64 and 7 in clipping vector data for display? I attached 2 pictures created with d.mon png and cairo driver Which is png and which is cairo? the map70.png is cairo, the other one is png. (to avoid influences from GUI) and you can see that in 64 the lines are clipped to match computational region while in grass7 it seems to display all vector features which have at least part in the region. Is this bug or feature? I couldn't find any discussion on this topic... In 7.0, there are two distinct sets of clipping operations. D_set_clip_mode, D_set_clip and D_clip_to_map control clipping which is performed within the display library. The default is no clipping. Using this functionality for graphical clipping is problematic if you use thick lines, as clipped lines will be capped at the point where they're clipped. It would also affect the dash offset for dashed lines (although that isn't implemented yet). Is there any way to set different default mode without modifying the code? Additionally, the driver's Set_window function establishes a clip region (e.g. via cairo_clip() for the cairo driver). This defaults to the entire screen, but can be overridden by setting the environment variable GRASS_FRAME. Arguably, the code which sets up the coordinate system so that the current region just fits the display (D_setup) should also set the clip region to fit the current region. However, this is complicated slightly be the fact that there's no distinction between the display frame (either the screen or the frame set by GRASS_FRAME) and the current clip region, so setting a clip region would lose the only record of the frame. I still don't understand if the current behavior in 7 is intended and if so, why no vector clipping is better? Anna -- 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 GIS] #2421: Functions from CDHC lib have no prefix
#2421: Functions from CDHC lib have no prefix
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: cdhclib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by wenzeslaus):
Agreed, they should use prefix.
BTW, if somebody knows something about it, please go ahead and write some
documentation, there is none.
Even more by the way, does the
[http://grass.osgeo.org/programming7/shapiro1_8c_source.html#l00032
following syntax] mean something special?
{{{
(double).6872
}}}
I'm pretty sure that it is the same as writing just `.6872` but one never
knows with C.
For the other functions which might be similar case as cdhclib, we might
try to go through the elements in
[http://grass.osgeo.org/programming7/globals.html Globals section in
manual] but I'm not sure if all the things in the manual are public API, I
think they should be according to the Doxyfile settings:
{{{
EXTRACT_PRIVATE= NO
EXTRACT_STATIC = NO
...
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2421#comment:4
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] doxygen color style
On Tue, Sep 16, 2014 at 12:14 PM, Martin Landa landa.mar...@gmail.com wrote: 2014-09-16 17:50 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: When I tested this at my computer it was green (`make htmldox`). Be sure to reload the page (several times), browser might want to trick you. there shouldn't be any difference between `htmldox` and `htmldocs` commands. All commands produce on my PC blue-like style, will check more deeply later. Thanks for quick test, Martin I would check `svn status` for local modifications. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] doxygen color style
Hi, 2014-09-16 17:50 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: When I tested this at my computer it was green (`make htmldox`). Be sure to reload the page (several times), browser might want to trick you. there shouldn't be any difference between `htmldox` and `htmldocs` commands. All commands produce on my PC blue-like style, will check more deeply later. Thanks for quick test, 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 GIS] #2347: r.ros uses arbitrary direction convention
#2347: r.ros uses arbitrary direction convention -+-- Reporter: madi | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Default | Version: unspecified Keywords: r.ros, r.spread, angles |Platform: Unspecified Cpu: Unspecified | -+-- Changes (by wenzeslaus): * milestone: 6.4.4 = 7.1.0 Comment: If we would like to have this resolved in a way of choosing one direction, we would have to mark it as blocker for 7.0.0. However, I think this is not feasible and perhaps the better idea actually is to create a new option (for `r.ros` and `r.spread`) which will allow to choose between different conventions. If the default will be the same as the current it will not change the API and everything will be fine. So, increasing the milestone. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2347#comment:4 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] [GRASS GIS] #88: opt-guisection and opt-label for a better GUI world
#88: opt-guisection and opt-label for a better GUI world --+- Reporter: hamish | Owner: grass-dev@… Type: task | Status: closed Priority: minor| Milestone: 6.4.4 Component: Default | Version: unspecified Resolution: fixed|Keywords: guisection Platform: All | Cpu: All --+- Changes (by wenzeslaus): * status: new = closed * resolution: = fixed Comment: Replying to [comment:2 martinl]: Is this bug report still relevant? Apparently not, closing. Please, open a new ticket with a specific description of a given problem if needed. -- Ticket URL: https://trac.osgeo.org/grass/ticket/88#comment:3 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] GRASS7.1 experimental temporal framework update
Dear all, JFYI i have updated the temporal framework in grass7.1 trunk (last commit is r62000) to support distributed temporal databases. The new default behavior is that sqlite3 based temporal databases will be created in the current mapset. The temporal framework takes care of which mapset specific temporal database should be used for data access. Existing locations with temporal databases should work as usual. However, at the moment this works only with sqlite3 databases. Using several different postgresql database backends is untested. Mixing of sqlite and postgresql temporal databases in a single location is not possible. Some API changes were necessary to implement maspet specific temporal database management. I did not tested yet the temporal related GUI modules and code. Be aware that the temporal framework and the related modules in grass trunk (7.1 svn version) are highly experimental and should not be used in production. The new approach limits the use of SQL where and order statements in t.list. These statements will be performed for each temporal database, but not for the output of all databases together. Best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r61998 - grass/trunk/lib/python/pygrass/messages
On Tue, Sep 16, 2014 at 12:40 PM, svn_gr...@osgeo.org wrote: messgae = message[:1999] Is this a typo? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1113: layertree to be compatible with DataCatalog
#1113: layertree to be compatible with DataCatalog --+- Reporter: rashadkm | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.1.0 Component: wxGUI| Version: svn-develbranch6 Resolution: fixed|Keywords: data catalog Platform: All | Cpu: x86-32 --+- Changes (by wenzeslaus): * status: new = closed * resolution: = fixed * milestone: 6.5.0 = 7.1.0 Comment: This request is now addressed by source:grass/trunk/gui/wxpython/lmgr/datacatalog.py?rev=61849 for trunk. Closing as fixed and changing milestone accordingly. For bugs and missing features, please open new tickets. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1113#comment:4 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] [GRASS GIS] #2422: Functions from Segment lib have no prefix
#2422: Functions from Segment lib have no prefix
-+--
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibRaster| Version: unspecified
Keywords: segmentlib, api, prefix |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by mmetz):
Replying to [ticket:2422 martinl]:
In contrast to other GRASS libs, Segment lib (1) doesn't use any prefix.
The prefix used by the segment lib is segment_.
I would suggest to change eg.
{{{
segment_open()
}}}
to
Replying to [comment:2 martinl]:
{{{
Segment_open()
}}}
So you mean to change the first letter of the prefix to upper case?
E.g. Rast_segment_open does not make sense to me because the segment
library is standalone and not part of the raster library.
Currently library functions for each library have their own prefix (that
happened also when splitting gis lib in gis lib and raster lib). This
convention makes work for developers easier and I would suggest to keep
it. Thus e.g. Rowio_get() is just fine, no need to mask it as a raster
lib function, it is a rowio lib function.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2422#comment:4
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] [GRASS-SVN] r61998 - grass/trunk/lib/python/pygrass/messages
Am 16.09.2014 20:13 schrieb Vaclav Petras wenzesl...@gmail.com: On Tue, Sep 16, 2014 at 12:40 PM, svn_gr...@osgeo.org wrote: messgae = message[:1999] Is this a typo? Ooops, it is a typo, ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #969: move color structs to colors.h?
#969: move color structs to colors.h?
--+-
Reporter: hamish| Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Keywords: RGBA_Color, G_str_to_color() |Platform: All
Cpu: All |
--+-
Comment(by mmetz):
Replying to [comment:3 wenzeslaus]:
Replying to [comment:2 neteler]:
Would this count as an API change? Then make it a blocker or change to
GRASS GIS 8 target.
It is an API change.
RGBA_Color moved to include/display.h in r62002,3 (it is only used in
display functions).
Should we also change `G_str_to_color()`? This would be a blocker too.
IMHO no, because there is no bug reported for `G_str_to_color()`, using
`unsigned char` instead of `int` means that a range check can no longer be
done, and changing `G_str_to_color()` implies changing
{{{
display/d.barscale/draw_scale.c
display/d.extract/main.c
display/d.graph/do_graph.c
display/d.graph/main.c
display/d.grid/fiducial.c
display/d.labels/color.c
display/d.northarrow/draw_n_arrow.c
display/d.path/main.c
display/d.rast/display.c
display/d.thematic.area/main.c
display/d.thematic.area/plot1.c
display/d.vect.chart/main.c
display/d.vect/opt.c
display/d.vect/shape.c
general/g.cairocomp/main.c
general/g.pnmcomp/main.c
lib/cairodriver/Graph.c
lib/display/tran_colr.c
lib/imagery/iclass_signatures.c
lib/imagery/iclass_statistics.c
lib/nviz/nviz.c
lib/ogsf/Gp3.c
lib/ogsf/Gv3.c
lib/pngdriver/Graph_set.c
lib/raster/color_hist.c
misc/m.nviz.image/main.c
ps/ps.map/do_labels.c
ps/ps.map/getgrid.c
ps/ps.map/ps_outline.c
ps/ps.map/ps_vareas.c
ps/ps.map/ps_vlines.c
ps/ps.map/ps_vpoints.c
ps/ps.map/r_border.c
ps/ps.map/r_colortable.c
ps/ps.map/r_header.c
ps/ps.map/r_info.c
ps/ps.map/r_instructions.c
ps/ps.map/r_plt.c
ps/ps.map/r_text.c
ps/ps.map/r_vareas.c
ps/ps.map/r_vlegend.c
ps/ps.map/r_vlines.c
ps/ps.map/r_vpoints.c
ps/ps.map/r_wind.c
raster/r.out.png/main.c
raster/r.out.tiff/main.c
vector/v.colors/read_rgb.c
vector/v.to.rast/support.c
}}}
Thus the benefit of changing a harmless type cast comes at a cost.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/969#comment:5
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] [GRASS GIS] #2423: r.series.interp missing in wxGUI menu
#2423: r.series.interp missing in wxGUI menu --+- Reporter: jbrauner | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.1.0 Component: wxGUI | Version: svn-trunk Keywords: r.series.interp, wxGUI, menu |Platform: All Cpu: All | --+- Hi devs, r.series.interp is missing in wxGUI menu. I created a patch (attached) to add it just below r.series in the Raster - Overlay submenu as Raster series interpolation. This is just a suggestion, feel free to place it anywhere else. Hopefully I've modified the correct toolboxes.xml - newbie :). Cheers, Johannes -- Ticket URL: http://trac.osgeo.org/grass/ticket/2423 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] [GRASS GIS] #2417: r.profile should report distance in location units
#2417: r.profile should report distance in location units
+---
Reporter: annakrat| Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.1.0
Component: Projections/Datums | Version: svn-trunk
Keywords: r.profile, units|Platform: All
Cpu: Unspecified |
+---
Comment(by mlennert):
Replying to [comment:2 annakrat]:
The only problem is the name of the units which is in case of Foot_US
not recognized and `G_database_unit_name` gives just ''unit''. As a
result, r.profile now prints something like this
{{{
Output Format:
[Along Track Dist. (units)] [Elevation]
Approx. transect length [205.092833] units
...
}}}
but this is a different problem.
It seems to me that it should be possible to get the correct units name
from the PROJ_UNITS file, but I just can't find a library function to do
just that. I'm sure it must exist...
Moritz
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2417#comment:3
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] [GRASS GIS] #2424: PyGRASS does not work when GRASS is invoked from outside
#2424: PyGRASS does not work when GRASS is invoked from outside
--+-
Reporter: wenzeslaus| Owner:
grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 7.0.0
Component: Python ctypes | Version: svn-trunk
Keywords: installation, pygrass, temporal, scripts |Platform: MSWindows
8
Cpu: Unspecified |
--+-
When one want to
[http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
work with GRASS without starting it explicitly], it is possible to use
`grass.script` but it is not possible to use `grass.pygrass`,
`grass.temporal` and `grass.lib`.
This might have been discussed on mailing already, anyway the reason is
that the dynamic libraries are not accessible to the current process.
Output on Linux:
{{{
Traceback (most recent call last):
File ./run_grass_from_outside.py, line 62, in module
from grass.pygrass import vector
File /opt/src/grass-trunk/dist.x86_64-unknown-linux-
gnu/etc/python/grass/pygrass/__init__.py, line 7, in module
import grass.lib.gis as _libgis
File /opt/src/grass-trunk/dist.x86_64-unknown-linux-
gnu/etc/python/grass/lib/gis.py, line 23, in module
_libs[grass_gis.7.1.svn] = load_library(grass_gis.7.1.svn)
File /opt/src/grass-trunk/dist.x86_64-unknown-linux-
gnu/etc/python/grass/lib/ctypes_loader.py, line 55, in load_library
return self.load(path)
File /opt/src/grass-trunk/dist.x86_64-unknown-linux-
gnu/etc/python/grass/lib/ctypes_loader.py, line 71, in load
raise ImportError,e
ImportError: libgrass_datetime.7.1.svn.so: cannot open shared object file:
No such file or directory
}}}
Output on MS Windows:
{{{
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Anaconda\lib\site-
packages\spyderlib\widgets\externalshell\sitecustomize.py, line 523, in
runfile
execfile(filename, namespace)
File C:\Users\akratoc\test_grass_standalone.py, line 59, in module
from grass.pygrass import vector
File C:\Program Files (x86)\GRASS GIS
7.0.0beta3\etc\python\grass\pygrass\__init__.py, line 7, in module
import grass.lib.gis as _libgis
File C:\Program Files (x86)\GRASS GIS
7.0.0beta3\etc\python\grass\lib\gis.py, line 23, in module
_libs[grass_gis.7.0.0beta3] = load_library(grass_gis.7.0.0beta3)
File C:\Program Files (x86)\GRASS GIS
7.0.0beta3\etc\python\grass\lib\ctypes_loader.py, line 55, in
load_library
return self.load(path)
File C:\Program Files (x86)\GRASS GIS
7.0.0beta3\etc\python\grass\lib\ctypes_loader.py, line 221, in load
return _WindowsLibrary(path)
File C:\Program Files (x86)\GRASS GIS
7.0.0beta3\etc\python\grass\lib\ctypes_loader.py, line 207, in _init_
self.cdll = ctypes.cdll.LoadLibrary(path)
File C:\Anaconda\lib\ctypes\__init__.py, line 443, in LoadLibrary
return self._dlltype(name)
File C:\Anaconda\lib\ctypes\__init__.py, line 365, in _init_
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 193] %1 is not a valid Win32 application
}}}
It is unfortunate that you even cannot import `grass.pygrass.modules`:
{{{
from grass.pygrass import modules
}}}
For Linux, we have to rely on decision of packagers and a user being able
to manage `~/.bashrc` or environmental variables of the given process.
For MS Windows, the solution would be to allow user to add the variables
to the environment. It seems to me that it is enough to add path with
dynamic libraries (`lib` and `extrabin`) and GRASS installation directory
(the one with the `grass*.bat` file) to `PATH` and Python packages
(`etc/python`) to `PYTHONPATH`.
The solution is of course invasive but there is no other way. A lot of
applications just do the same without worrying about consequences. We can
try what Git for MS Windows is doing: giving a choice how git commands and
other tools should be spread into the system (modify or not modify the
`PATH`).
The question of course is what should be the default.
Other question is whether to add to the beginning or the end of `PATH` and
`PYTHONPATH` variables.
Also, there must be a warning (in MS Windows installer) that no other
version of GRASS GIS will work.
The same might apply to other OSGeo or related software. This is
unfortunately unknown. I guess that this option cannot be available in
OSGeo4W installer.
I have no idea about Mac OS X. Which solution would be appropriate there?
Do you have some other ideas how to solve or workaround this issue? Would
it be possible to provide a script/functionality in GRASS GIS which would
put the
Re: [GRASS-dev] [GRASS GIS] #131: Tool to assist creation (design) of simple scripts within from the wxpython-GUI
#131: Tool to assist creation (design) of simple scripts within from the wxpython-GUI --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: 6.5.0 Component: Python | Version: unspecified Resolution: fixed|Keywords: GUI, script creation Platform: Unspecified | Cpu: Unspecified --+- Changes (by wenzeslaus): * status: new = closed * resolution: = fixed Comment: Closing as fixed since we have the ''Save/Export as Python script'' in wxGUI Graphical Modeler. If something does not work or you want more functionality, please create a new ticket. -- Ticket URL: http://trac.osgeo.org/grass/ticket/131#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] [GRASS GIS] #2425: Import translation function instead of using a buildin
#2425: Import translation function instead of using a buildin
-+--
Reporter: wenzeslaus | Owner:
grass-dev@…
Type: task | Status: new
Priority: normal | Milestone: 7.1.0
Component: Translations | Version:
svn-releasebranch70
Keywords: python, underscore, _, gettext, doctest |Platform: All
Cpu: Unspecified |
-+--
''Here are my notes about this issue since I was forgetting about it.''
On some occasions, some of GRASS functions does not work because of
translation function (`_` - underscore). The problem occurs on some
strange conditions and when you are using Python
[https://docs.python.org/2/library/doctest.html doctest] which we are
using more and more.
There is already several workarounds in wxGUI and also testing framework
as
[wiki:GSoC/2014/TestingFrameworkForGRASS#Findingandrunningthetestmodules
described here]:
`doctests` currently don't work with grass.script unless you call a
[source:grass/trunk/gui/wxpython/core/toolboxes.py?rev=60218#L630 set of
functions] to deal with function _ (underscore) because of installing
translate function as buildin _ function while _ function is used also in
doctest.
Grep for function `do_doctest_gettext_workaround` to see definition and
how it is used.
I already did this change for wxGUI more then a year ago and it seems to
work. It was necessary because there was some problem with not translated
files and this was only way to fix it besides going against documentation.
For now I don't know how `lib/python`, `scripts`, and `temporal` differs
in translations, so this should be clarified before changing it.
See comment:5:ticket:1739 for deep discussion of the topic.
For wxGUI this was implemented in the r57219 and r57220 as a result of
#1739 and other investigation.
This might be a blocker for some solutions of #2142. The new method should
be flexible allowing to obtain translations from two sources
simultaneously.
Basically, it is necessary to remove all occurrences of:
{{{
gettext.install('grasswxpy', os.path.join(os.getenv(GISBASE), 'locale'),
unicode = True)
}}}
By one code based on this line in some module:
{{{
_ = gettext.translation('grasswxpy', os.path.join(os.getenv(GISBASE),
'locale')).ugettext
}}}
The actual implementation must be more complicated
(changeset:57220#file0).
Then each file, depending on the name and placement of translation
function, must import:
{{{
from grass.script.utils import _
from grass.script.translations import _
from grass.*.utils import _
from grass.*.translations import _
from grass.translations import _
}}}
Probably `grass.translations` is the best since in GUI a module inside
some other package is creating dependencies (changeset:57219#file10,
changeset:57219#file13).
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2425
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] [GRASS GIS] #1739: Language switch on wxGUI doesn't affect all strings
#1739: Language switch on wxGUI doesn't affect all strings ---+ Reporter: MilenaN | Owner: grass-dev@… Type: defect| Status: closed Priority: normal| Milestone: 7.0.0 Component: Translations | Version: unspecified Resolution: fixed |Keywords: wxGUI, Python, underscore, _, gettext, doctest Platform: All | Cpu: x86-32 ---+ Changes (by wenzeslaus): * keywords: = wxGUI, Python, underscore, _, gettext, doctest * resolution: = fixed * status: new = closed * component: Python = Translations * milestone: 6.4.4 = 7.0.0 Comment: Replying to [comment:6 marisn]: It should work just fine in GRASS 7 as long as specified language has its supporting locale installed. If language lacks matching locale in the system, I'm not certain if it can be solved at all. As GRASS 6 and 7 startup scripts are different, it is not possible to backport changes. I would vote for testing in 7 and closing as wontfix for 6. No complains since then, so closing as fixed. Feel free open a new ticket if you encounter any other problems. Related/unresolved: * The issue remains for library and modules, follow #2425. * Smaller issue related to toolboxes is inside of #2142. * r57219 has some code duplication (visible in r57220) which should be removed in the future (the solution is probably a separate `(wxgui.)translations` package/module). -- Ticket URL: http://trac.osgeo.org/grass/ticket/1739#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
Re: [GRASS-dev] GRASS7.1 experimental temporal framework update
Hi Soeren, On Tue, Sep 16, 2014 at 7:15 PM, Sören Gebbert soerengebb...@googlemail.com wrote: Dear all, JFYI i have updated the temporal framework in grass7.1 trunk (last commit is r62000) to support distributed temporal databases. The new default behavior is that sqlite3 based temporal databases will be created in the current mapset. The temporal framework takes care of which mapset specific temporal database should be used for data access. Existing locations with temporal databases should work as usual. Thanks a lot for your efforts! Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
