Re: [GRASS-dev] [GRASS GIS] #2120: wxgui: encoding errors

2014-05-17 Thread GRASS GIS
#2120: wxgui: encoding errors -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4

Re: [GRASS-dev] [GRASS GIS] #2120: wxgui: encoding errors

2014-05-17 Thread GRASS GIS
#2120: wxgui: encoding errors -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4

Re: [GRASS-dev] [GRASS GIS] #2120: wxgui: encoding errors

2014-05-17 Thread GRASS GIS
#2120: wxgui: encoding errors -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4

Re: [GRASS-dev] [GRASS GIS] #2293: MapSwipe query maps

2014-05-17 Thread GRASS GIS
#2293: MapSwipe query maps +--- Reporter: lucadelu| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal |

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

2014-05-17 Thread Yann Chemin
Hi Anna, Patch works great ! Needs RunMenuCmd and all goes to perfection. Any chance to have it included in the SVN tree? Thank you Yann On 18/05/2014, Anna Petrášová wrote: > Hi Yann, > > it's grayed out because it tests if it's a working grass command (for > example r.in.lidar is grayed when

Re: [GRASS-dev] wiki pages for GSoc projects

2014-05-17 Thread Vaclav Petras
On Wed, May 14, 2014 at 10:53 AM, Martin Landa wrote: > Hi, > > 2014-05-14 15:32 GMT+02:00 Vaclav Petras : > > Hi, Trac wiki is the right choice, IMHO. There is somewhere an email > > explaining all the reasons for it. The student's GSoC page should be > subpage > > of GSoC/2014, e.g. GSoC/2014/Me

Re: [GRASS-dev] [GRASS GIS] #2277: graphically set up region bounds

2014-05-17 Thread GRASS GIS
#2277: graphically set up region bounds --+- Reporter: vincent | Owner: martinl Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: wxGUI

Re: [GRASS-dev] wxGUI customized toolboxes: handler for non-GRASS commands

2014-05-17 Thread Anna Petrášová
Hi Yann, it's grayed out because it tests if it's a working grass command (for example r.in.lidar is grayed when you don't compile grass with liblas). You can try to apply this patch which tests if the command looks like grass command (regular expression) and if it is not, it doesn't disable it in

[GRASS-dev] [GRASS GIS] #2296: r.stream.* - unify some functions (avoid code duplication)

2014-05-17 Thread GRASS GIS
#2296: r.stream.* - unify some functions (avoid code duplication) -+-- Reporter: hellik | Owner: grass-dev@… Type: enhancement | Status: new Priority: major

Re: [GRASS-dev] [GRASS GIS] #2293: MapSwipe query maps

2014-05-17 Thread GRASS GIS
#2293: MapSwipe query maps +--- Reporter: lucadelu| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal |

Re: [GRASS-dev] [GRASS GIS] #1628: segfault in r.walk

2014-05-17 Thread Glynn Clements
GRASS GIS wrote: > I have removed the lib/sites dependency of v.vol.rst in 7.x in r60272 > (trunk) and r60273 (relbr7). That appears to leave v.in.sites as the only client of lib/sites. And it only uses the "oldsite" functionality (i.e. reading GRASS 5.x "sites" maps), as opposed to using the

Re: [GRASS-dev] GRASS & QGIS: the future

2014-05-17 Thread Glynn Clements
Radim Blazek wrote: > > Also, currently the global error handler (G_set_error_routine) is > > called before the non-exclusive handlers (G_add_error_handler), so > > those will never be called if the global handler lonjmp()s out. The > > global error handler isn't limited to fatal errors, but is a

Re: [GRASS-dev] Metadata GRASS (GSOC)

2014-05-17 Thread Newcomb, Doug
I heard yesterday that EPA is releasing a new version of their metadata tool , doing away with the access database and writing everything to xml files. It's being written in C#, but they plan on putting the source code on github. Not sure of the timeline. Doug On Sat, May 17, 2014 at 3:19 AM,

Re: [GRASS-dev] Metadata GRASS (GSOC)

2014-05-17 Thread Matej Krejci
Hi, > I was wondering was whether it would be possible to extract from pycsw > just the part for reading/writing the xml meta-data, without all the > overhead linked to its status as a server. > > > More generally, I just think that we can't be the only ones working on > metadata in a Python e