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

[GRASS GIS]

#2296: r.stream.* - unify some functions (avoid code duplication)
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  major|  Milestone:  7.0.4
 Component:  Addons   |Version:  svn-trunk
Resolution:   |   Keywords:  r.stream.*
   CPU:  All  |   Platform:  All
--+-

Comment (by hellik):

 Replying to [comment:12 mlennert]:
 > Can this be closed ?

 AFAIK not completed yet.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Interest in GSoC 2016

[Ondra.Lobo]

Hi,

My name is Ondřej Pešek and I am student of Czech Technical University in 
Prague.  I am in the last year of bachelor studium (geodesy, cartography and
geoinformatics). My bachelor thesis is development of QGis plugin (for 
aerial data leveling). I’m developing in python and I have some basics in C+
+. Often I work also with other gis programs (ArcGis). I am very interested 
in co-working with Grass for Google Summer of Code 2016. 

My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is 
increasingly used (look at QGis, for example) and I think it would be better
to have minimally the roots of GUI in Qt. It’s also much easier to maintain 
with new features. Work with design is also much more user-friendly. It 
seems that in the future, it can be nice shortcut to change something in the
GUI. 

Thanks and I’m looking forward for your answers, 

Ondřej Pešek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Vaclav Petras]

On Wed, Mar 16, 2016 at 1:27 PM, Markus Neteler  wrote:

>
> I just needed r.rgb and found the script broken: must be a silly bug
> but I don't see it..:
>
> # NC
>
> GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
>
> syntax error, unexpected $end, expecting VARNAME or NAME or STRING
> Parse error
> ERROR: parse error
> ERROR: An error occurred while running r.mapcalc
>
> Any idea?



Not all options are required but at least one of them:

https://trac.osgeo.org/grass/changeset/68072
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] split GRASS (lib / cli / modules / wx / qt / web / etc.)

[Pietro]

On Fri, Mar 18, 2016 at 2:16 PM, Moritz Lennert
 wrote:
> On 18/03/16 12:58, Pietro wrote:
> In your opinion is this true at the module level, or mostly for the wxGUI ?

No in my opinion things are quite mixed also in C/python modules.


>> Let's start with a simple example: most of the GRASS modules, mix
>> nicely logic and cli, several of them have a single main function with
>> everything inside. I think could be useful to have a more clear
>> distinction between logic/algorithms and their public interface
>> (cli/gui).
>
>
> Why ? I really like the fact that each module works kind of like a
> high-level function with a defined public interface.

Yes, and I like too! Indeed I don't want to change this. What I would
like to change is to better distinguish this high-level
functionalities from the low level parts. So for instance just opening
randomly a GRASS core module: r.resamp.stats

https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.resamp.stats/main.c

here are defined:
- static const struct menu, that probably could be useful also for
other modules so should go to the grass-lib
- static char *build_method_list(void), that could be generalized to
used also from other modules and should go to the grass-lib
- static int find_method(const char *name), could be also generalized
to be used by other modules and should go to the grass-lib
- static void resamp_unweighted(void), this function could be also
changed to be more general and moved to the grass-lib too
- static void resamp_weighted(void), same as before.

For each of the above function we can build tests to improve the
reliability, verify performance regression and so on.

So far you can access to this functions only from the CLI interface,
if we clear separate this two level then we can access to this using
CLI, but also using C/python/etc. So for instance If I need select an
option from a menu list on a new module I have to reinvent the wheel,
write my own buggy code and as GRASS developers we end up having
duplicate buggy code in each module.

The main function could stay or be rewritten in python, this is not
really relevant because it is just defining the CLI interface and
calling the functions and finally adding the history metadata and set
the color table.



>> If we clearly split these two things the GRASS modules
>> became just an interface to some functions inside the GRASS libraries.
>
>
> Many modules (if not most) are already that: a combination of GRASS library
> function calls in order to achieve the specific goal the module is set out
> for.

yes they are calling GRASS library functions, but they are also adding
functionalities that (imho) should be included to the GRASS library.
Because they could be useful not only for this specific modules but
also for others.


>> So how to split GRASS. It  would be nice to open a dedicate repository
>> (git?) for each of this projects:
>>
>> - grass-lib: provides only C and Python API. This component should be
>> a python citizen, I mean that should be available at the PyPI - the
>> Python Package Index [1] and of course install-able as python package
>> through pip;
>> - grass-cli: provides a shell (with no modules!), also available as a
>> pure python package;
>
>
> I'm not sure I like this extremely pythonic approach to GRASS. I love to use
> Python for scripting GRASS, but in my perception GRASS is far from being a
> Python project.

mmh, ok, so let's add a more layer: grass-lib, grass-py, and then the others..

So grass-lib will contain only C (C++?) code and will be not available
at the PyPi website.
grass-py add the python wrap to grass-lib and add API and go to PyPi.

This is the same approach of GDAL[0], PROJ4[1], mapnik[2] that are all
available as python packages.

I do think that add grass to PyPi can only open new prospective and
use cases reaching a broader group of users and developers.


>> - grass-modules: provides all the GRASS core modules (this could be
>> also a pure python interface calling functions in the C/Python
>> libraries), and could be split in other sub categories (e.g. imagery,
>> temporal, terrain, etc).
>
>
> What is the difference between these modules and the existing ones ? Except
> for your idea to make all module Python modules.

Because things are complicated and the current status quo is not
flexible and/or very limited.
Basically you can create python packages that act as both library and
grass-addons.
So for instance the r.green modules require scipy and numexpr to run,
and the only way available in 2016 is that user have to care about it
installing the missing libraries and even worst if some of our modules
depend on another addons there is no way to handle this.

Other things that are not working with the current set up is that
there is not way to said for each version of grass the addon is
available.
So for instance r.green was developed and tested with grass7 stable,
Sören has improved pygrass vector API in 

Re: [GRASS-dev] Interest in GSoC 2016

[Ondra.Lobo]

Hi Vaclav

On Thu, Mar 17, 2016 at 9:44 PM,  wrote:
"

To make it really work, I think, it is necessary to use the generic part 
code also for the current GUI besides using it for the prototype of Qt-based
GUI. This would ensure that the new code is actually used right away. It 
would also ensure few more other important things already described at the 
wiki.

"






Yeah, the original idea came from wiki, I've read it. I will need some time 
to deeply explore GRASS GUI. But I believe it could be fun... 





Thanks for your response, 


Ondrej







___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in contributing

[Djimeli Konrad]

Hello Luca,

Thanks for the pointers. I have been doing some research and studying
the information on the links you provided and I am confident I would
be able to execute the project. I am presently working on my  proposal
and looking for a starting to work on as part of my proposal.

Thanks
Konrad
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2936: v.net.distance: wrong directions in one-way streets

[GRASS GIS]

#2936: v.net.distance: wrong directions in one-way streets
-+-
  Reporter:  mlennert|  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.0.4
 Component:  Vector  |Version:  svn-trunk
Resolution:  fixed   |   Keywords:  v.net.distance network one-way
   CPU:  |  direction
  Unspecified|   Platform:  Unspecified
-+-
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closing as the bug has been fixed in trunk and release70.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Markus Neteler]

On Wed, Mar 16, 2016 at 9:24 PM, Vaclav Petras  wrote:
>
> On Wed, Mar 16, 2016 at 1:27 PM, Markus Neteler  wrote:
>>
>>
>> I just needed r.rgb and found the script broken: must be a silly bug
>> but I don't see it..:
>>
>> # NC
>>
>> GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
>>
>> syntax error, unexpected $end, expecting VARNAME or NAME or STRING
>> Parse error
>> ERROR: parse error
>> ERROR: An error occurred while running r.mapcalc
>>
>> Any idea?
>
>
>
> Not all options are required but at least one of them:
>
> https://trac.osgeo.org/grass/changeset/68072

I see, that now works:

GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
Description:
 Splits a raster map into red, green and blue maps.
Keywords:
[...]
ERROR: At least one of the following options is required: ,
 and 

ok. But another error occurs (missing error handling if the output
names were selected to be identica):

GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation
red=elevation green=elevation blue=elevation
syntax error, unexpected '=', expecting '('
Parse error
ERROR: parse error
ERROR: An error occurred while running r.mapcalc

Eventually this works:
r.rgb input=elevation red=elevation.r green=elevation.g blue=elevation.b

Perhaps there is an elegant solution to catch the (user) error above?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] is OSGeo4W GRASS 7.0.3 working?

[Anna Petrášová]

Thanks for looking into this, it works now!

Anna

On Tue, Mar 8, 2016 at 4:45 AM, Martin Landa  wrote:

> Hi,
>
> 2016-03-08 10:34 GMT+01:00 Jürgen E. :
> > Not sure what still depends on spatialite4.dll then.  I just noticed
> that in
> > https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/gdal.c#L117
> the
> > DLLs are explictly listed, gdal200.dll is missing and gdal110.dll links
> > spatialite4.dll.
>
> yes, but `gdal111.dll` should be found first. I added support for
> GDAL2, thanks for reminder. Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/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] #2966: r.sim.water not working in 7.0.3 32bit and 64bit

[GRASS GIS]

#2966: r.sim.water not working in 7.0.3 32bit and 64bit
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  7.0.3
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by baharmon):

 n.b.: Just a problem on Windows. (I made a typo before.)

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Size & (re)sizable Location Wizard dialog please

[Anna Petrášová]

On Sat, Mar 12, 2016 at 11:40 AM, Yann  wrote:

> Hi,
>
> https://grasswiki.osgeo.org/wiki/File:Location_wizard_with_IAU_codes.png
>
> The text goes out of the box, most probably because of some settings in my
> PC.
> Is it possible to let the dialog box adapt to a larger size if needed, or
> being manually resizable.
>
> Could you try the attached diff? I am not really sure about the change.

Anna


> Thank you,
> Yann
>
> --
> -
> Yann Chemin
> Address: 3 Toul Melin, 56400 Plumergat
> Mobile: +33 (0)7 83 85 52 34
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
Index: datacatalog/catalog.py
===
--- datacatalog/catalog.py  (revision 68055)
+++ datacatalog/catalog.py  (working copy)
@@ -42,6 +42,8 @@
 self.thread = gThread()
 self._loaded = False
 self.tree.showNotification.connect(self.showNotification)
+self.reload_btn = wx.Button(self, label=_("Refresh"))
+self.reload_btn.Bind(wx.EVT_BUTTON, self.OnReload)
 
 # some layout
 self._layout()
@@ -49,7 +51,10 @@
 def _layout(self):
 """Do layout"""
 sizer = wx.BoxSizer(wx.VERTICAL)
-
+hsizer = wx.BoxSizer(wx.HORIZONTAL)
+hsizer.AddStretchSpacer()
+hsizer.Add(self.reload_btn, flag=wx.EXPAND)
+sizer.Add(hsizer, flag=wx.EXPAND)
 sizer.Add(item = self.tree.GetControl(), proportion = 1,
   flag = wx.EXPAND)  
 
@@ -68,3 +73,6 @@
 def LoadItemsDone(self):
 self._loaded = True
 self.tree.ExpandCurrentMapset()
+
+def OnReload(self, event):
+self.tree.Reload()
Index: datacatalog/tree.py
===
--- datacatalog/tree.py (revision 68055)
+++ datacatalog/tree.py (working copy)
@@ -91,6 +91,65 @@
 gscript.try_remove(tmp_gisrc_file)
 
 
+
+def map_exists(name, element, env, mapset=None):
+"""Check is map is present in the mapset given in the environment
+
+:param name: name of the map
+:param element: data type ('raster', 'raster_3d', and 'vector')
+:param env environment created by function getEnvironment
+"""
+if not mapset:
+mapset = gscript.run_command('g.mapset', flags='p', env=env).strip()
+# change type to element used by find file
+if element == 'raster':
+element = 'cell'
+elif element == 'raster_3d':
+element = 'grid3'
+# g.findfile returns non-zero when file was not found
+# se we ignore return code and just focus on stdout
+process = gscript.start_command('g.findfile', flags='n',
+element=element, file=name, mapset=mapset,
+stdout=gscript.PIPE, stderr=gscript.PIPE, 
env=env)
+output, errors = process.communicate()
+info = gscript.parse_key_val(output, sep='=')
+# file is the key questioned in grass.script.core find_file()
+# return code should be equivalent to checking the output
+if info['file']:
+return True
+else:
+return False
+
+
+class NameEntryDialog(TextEntryDialog):
+def __init__(self, element, mapset, env, **kwargs):
+TextEntryDialog.__init__(self, **kwargs)
+self._element = element
+self._mapset = mapset
+self._env = env
+id_OK = self.GetAffirmativeId()
+self.Bind(wx.EVT_BUTTON, self.OnOK, self.FindWindowById(id_OK))
+
+def OnOK(self, event):
+new = self.GetValue()
+if not new:
+return
+if map_exists(new, self._element, self._env, self._mapset):
+dlg = wx.MessageDialog(self, message=_("Map of type {elem} 
<{name}> already exists in mapset {mapset}. "
+   "Do you want to overwrite 
it?").format(elem=self._element,
+ name=new, mapset=self._mapset),
+   caption=_("Overwrite?"), style=wx.YES_NO)
+if dlg.ShowModal() == wx.ID_YES:
+dlg.Destroy()
+self._env['GRASS_OVERWRITE'] = '1'
+self.EndModal(wx.ID_OK)
+else:
+dlg.Destroy()
+return
+else:
+self.EndModal(wx.ID_OK)
+
+
 class DataCatalogNode(DictNode):
 """Node representing item in datacatalog."""
 def __init__(self, label, data=None):
@@ -146,7 +205,7 @@
 location_nodes = []
 nlocations = len(locations)
 grassdata_node = self._model.AppendNode(parent=self._model.root,
-label=_('GRASS locations 
({})').format(self.gisdbase),
+label=_('GRASS locations in 
{}').format(self.gisdbase),
  

[GRASS-dev] [GRASS GIS] #2965: r.neighbors explain count in manual

[GRASS GIS]

#2965: r.neighbors explain count in manual
+-
 Reporter:  marisn  |  Owner:  grass-dev@…
 Type:  enhancement | Status:  new
 Priority:  minor   |  Milestone:  7.1.0
Component:  Raster  |Version:  svn-trunk
 Keywords:  r.neighbors, documentation  |CPU:  Unspecified
 Platform:  Unspecified |
+-
 Currently description of r.neighbors does not clarify what will be counted
 - non-null cells or non-null, including 0. A small clarification based on
 code is required.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2917: r.mapcalc neighbour modifier uses wrong row

[GRASS GIS]

#2917: r.mapcalc neighbour modifier uses wrong row
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 I would suggest that we close this bug as it is fixed. Maris, would you be
 willing to put your initial idea concerning communication about such bugs
 into an RFC on the [https://trac.osgeo.org/grass/wiki/RFC trac wiki] ?
 Then we can put it to a vote to the PSC.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] changes in r.in.aster

[Carlos Grohmann]

Hi all

After an unsuccessful import of ASTER images, I went looking into the
r.in.aster script and made a few changes that allowed me to import
correctly the images.

OS: Mac OSX El Capitan (with Michael's binary version 7.0.3)

The original issues: The individual bandas were being imported with 15m
resolution for all bands (the region wasn't being re-set for the coarser
resolutions), and all bands imported after 3B had the southern section of
the 3B band (the temp file wasn't being reseted).

My changes:

1 - I changed the band names from 1,2,3b... to 01, 02, 03b... so they are
listed in the right order by the gui (instead of 1, 10, 11,...)

2 - I moved the lines:

tempfile = grass.read_command("g.tempfile", pid = os.getpid()).strip() +
'.tif'

grass.try_remove(tempfile)

to the loop:

if proctype in ["L1A", "L1B"]:
for band in bandlist:
if band in allbands:

so the tempfile is created and destroyed for each band, assuring it is
created according to the band spatial extent and resolution.


3 - This line was giving me errors:
if platform.system() == "Darwin":
cmd = ["arch", "-i386", "gdalwarp", "-t_srs", proj, srcfile,
tempfile ]

arch: posix_spawnp: gdalwarp: Bad CPU type in executable


This is probably because I run OSC El Cap, which is 64bits. So to get it
working, I had to ignore this system test and use

cmd = ["gdalwarp", "-t_srs", proj, srcfile, tempfile ]

Nut I'm not sure what would be the best way to keep the test and maintain
compatibility with older systems. Perhaps a try/except would do.


I attached the modified version.

best

Carlos



-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.


r.in.aster2
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2959: r.viewshed, r.terraflow and i.atcorr broken in 32/64bit builds

[GRASS GIS]

#2959: r.viewshed, r.terraflow and i.atcorr broken in 32/64bit builds
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Compiling   |Version:  7.0.3
Resolution:  |   Keywords:  c++, r.viewshed, r.terraflow,
 |  i.atcorr, mingw64, mingw
   CPU:  All |   Platform:  MSWindows 8
-+-

Comment (by annakrat):

 I attached a message I get on Windows, perhaps might be helpful.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2959: r.viewshed, r.terraflow and i.atcorr broken in 32/64bit builds

[GRASS GIS]

#2959: r.viewshed, r.terraflow and i.atcorr broken in 32/64bit builds
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  blocker |  Milestone:  7.0.4
 Component:  Compiling   |Version:  7.0.3
Resolution:  |   Keywords:  c++, r.viewshed, r.terraflow,
 |  i.atcorr, mingw64, mingw
   CPU:  All |   Platform:  MSWindows 8
-+-
Changes (by annakrat):

 * Attachment "error_viewshed.png" added.

 error message

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2964: G7: v.extract does not remove islands

[GRASS GIS]

#2964: G7: v.extract does not remove islands
--+---
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Vector   |Version:  7.0.3
Resolution:  fixed|   Keywords:  v.extract,islands
   CPU:  Unspecified  |   Platform:  All
--+---
Changes (by sbl):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Thanks for clarifying and updating the manuals!

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] FOSS4G 2016 - Call for Submissions!

[Moritz Lennert]

On 18/03/16 00:15, Luca Delucchi wrote:

On 17 March 2016 at 18:52, Markus Neteler  wrote:



I'm happy to propose a workshop.



I can help you...


I'm submitting a paper for the scientific track. I am more than willing 
to also help out with a workshop, but I don't want to commit to writing 
a proposal between now and Monday.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r68077 - in grass/branches/releasebranch_7_0/scripts: r.blend r.rgb

[Vaclav Petras]

Markus, all,

On Fri, Mar 18, 2016 at 10:09 AM,  wrote:

> Author: neteler
> Date: 2016-03-18 07:09:42 -0700 (Fri, 18 Mar 2016)
> New Revision: 68077
>
> r.rgb: more keywords; fix example; r.blend manual: add r.rgb reference
> (trunk, r68076)
>
>  
>  g.region raster=elevation -p
> -r.rgb input=elevation
> +r.rgb input=elevation red=elevation.r green=elevation.g blue=elevation.b
>  
>
>

I know we have dot in map names in lot of places but I though we want to
advertise underscore now because it works with vectors and database tables
(as well as columns).

Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] FOSS4G 2016 - Call for Submissions!

[Martin Landa]

Hi Markus, Luca,

2016-03-18 0:15 GMT+01:00 Luca Delucchi :
> I can help you...

you can count with me too. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2965: r.neighbors explain count in manual

[GRASS GIS]

#2965: r.neighbors explain count in manual
--+
  Reporter:  marisn   |  Owner:  marisn
  Type:  enhancement  | Status:  assigned
  Priority:  minor|  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.neighbors, documentation
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by marisn):

 * owner:  grass-dev@… => marisn
 * status:  new => assigned


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in contributing

[Luca Delucchi]

On 17 March 2016 at 00:30, Djimeli Konrad  wrote:
> Hello Luca,
>

Hi Konrad,

> Thanks for the pointers. I have been doing some research and studying
> the information on the links you provided and I am confident I would
> be able to execute the project. I am presently working on my  proposal
> and looking for a starting to work on as part of my proposal.
>

ok, if you need any help, you can also write me privately

> Thanks
> Konrad


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2909: g.gui.gmodeler - all layers rewritten by last output for more than one parameter

[GRASS GIS]

#2909: g.gui.gmodeler - all layers rewritten by last output for more than one
parameter
+-
  Reporter:  lfurtkevicova  |  Owner:  martinl
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.4
 Component:  wxGUI  |Version:  svn-trunk
Resolution:  fixed  |   Keywords:  gmodeler
   CPU:  Unspecified|   Platform:  Unspecified
+-
Changes (by martinl):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:5 lfurtkevicova]:
 > works for me, please backport if needed!

 Done in r68082. Closing, feel free to reopen if needed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2944: g.gui.gmodeler - strange duplicity when setting comment

[GRASS GIS]

#2944: g.gui.gmodeler - strange duplicity when setting comment
+-
  Reporter:  lfurtkevicova  |  Owner:  martinl
  Type:  enhancement| Status:  closed
  Priority:  minor  |  Milestone:  7.0.4
 Component:  wxGUI  |Version:  svn-trunk
Resolution:  fixed  |   Keywords:  g.gui.gmodeler, Set Comment
   CPU:  x86-64 |   Platform:  Linux
+-
Changes (by martinl):

 * status:  assigned => closed
 * resolution:   => fixed


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2944: g.gui.gmodeler - strange duplicity when setting comment

[GRASS GIS]

#2944: g.gui.gmodeler - strange duplicity when setting comment
+-
  Reporter:  lfurtkevicova  |  Owner:  martinl
  Type:  enhancement| Status:  assigned
  Priority:  minor  |  Milestone:  7.0.4
 Component:  wxGUI  |Version:  svn-trunk
Resolution: |   Keywords:  g.gui.gmodeler, Set Comment
   CPU:  x86-64 |   Platform:  Linux
+-

Comment (by martinl):

 Replying to [comment:2 lfurtkevicova]:
 > It is fixed, thanks, backport if needed ..

 Backported in r68081. Closing, feel free to re-open if needed.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GSOC] Suggestion for a Crowd-sourcing Geo-Processing Project

[Saad Qureshi]

Hi,

My name is Saad Qureshi and I am currently a 3rd Year Electrical
Engineering Student at NUST, Pakistan.

I got a chance to read through all the projects that *OSGeo *is working on
and I would like to recommend an innovative project that me and my friends
have been working on for a few months which, if implemented completely,
might prove very useful for the *OSGeo *community. The project is available
on github and you can get a basic overview of the project on main README.md
file:

https://github.com/msaadq/aero2

The project works like this:

Our volunteers or general athletes use our arm-band (BT enabled with MQ-5
sensor) to collect small samples (without them noticing) during their
commute or walking/running sessions from different parts of a city.

We collect that data from our database and relate it to certain properties
of different nodes of a city to a specified resolution (50x50 metres in our
case) and use the samples (of some nodes) and properties (of all nodes) to
predict the samples for the rest of the nodes without physical sampling.

I want to make a formal proposal for this project, but I wanted your
feedback on it first.

This Project has a hardware module, android application module and 2
backend modules.

Hardware:
- Interfaces the MQ-5 sensor and Bluetooth module with the ARM Cortex
M4 processor for data acquisition over Bluetooth and sending it directly to
the android app (Completed)

Android Application:
- Uses Mapbox API to visualize the data as heat maps overlay over
google maps for both sampled and resultant data and allows the user to
enable the sensor remotely for collecting samples. (Completed)

Backend:
- A Python-based backend for collecting the properties of a city using
MapsAPI and saving them in a database for later (Partially Implemented)
- A Python-based machine learning implementation for using the samples
(of some nodes) and properties (of all nodes) to predict the samples for
the rest of the nodes. (Not Implemented)

This is one of those projects for which I wake up every morning and it
would be really awesome if I get to work on this during GSOC. Your feedback
regarding this project (and its implementation is highly appreciated).

*Please let me know if this project resonates with the interests of **OSGeo**,
so that I start making a format proposal*

Saad Qureshi
www.linkedin.com/in/msaadq
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r68077 - in grass/branches/releasebranch_7_0/scripts: r.blend r.rgb

[Glynn Clements]

Vaclav Petras wrote:

> I know we have dot in map names in lot of places but I though we want to
> advertise underscore now because it works with vectors and database tables
> (as well as columns).

Maybe if people keep using a dot, someone will eventually care enough
about the broken 5.3 vector changes to fix the issue, rather than
expecting everyone else to work around it.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] FOSS4G 2016 - Call for Submissions!

[Luca Delucchi]

On 3 February 2016 at 09:52, Luca Delucchi  wrote:
> Is someone thinking to submit GRASS GIS workshop?
>

any news? monday is the deadline for submission... we should present
at least a workshop and a talk

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Interest in GSoC 2016

[Luca Delucchi]

On 17 March 2016 at 19:45,   wrote:
> Hi,
>

Hi Ondřej,

> My name is Ondřej Pešek and I am student of Czech Technical University in
> Prague.  I am in the last year of bachelor studium (geodesy, cartography and
> geoinformatics). My bachelor thesis is development of QGis plugin (for
> aerial data leveling). I’m developing in python and I have some basics in
> C++. Often I work also with other gis programs (ArcGis). I am very
> interested in co-working with Grass for Google Summer of Code 2016.
>
> My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
> increasingly used (look at QGis, for example) and I think it would be better
> to have minimally the roots of GUI in Qt. It’s also much easier to maintain
> with new features. Work with design is also much more user-friendly. It
> seems that in the future, it can be nice shortcut to change something in the
> GUI.
>
> Thanks and I’m looking forward for your answers,
>

Your proposal is really interesting.

What could you be able to port to Qt? Layer manager and map display?

> Ondřej Pešek
>


-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2917: r.mapcalc neighbour modifier uses wrong row

[GRASS GIS]

#2917: r.mapcalc neighbour modifier uses wrong row
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  blocker  |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:  fixed|   Keywords:  r.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by marisn):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:9 mlennert]:
 > Maris, would you be willing to put your initial idea concerning
 communication about such bugs into an RFC on the
 [https://trac.osgeo.org/grass/wiki/RFC trac wiki] ? Then we can put it to
 a vote to the PSC.
 >
 >
 Done. I created a GRASS GIS errata framework proposal page:
 https://trac.osgeo.org/grass/wiki/RFC/5_Errata

 Closing this issue as it is solved. Any discussion on communication with
 potentially affected users should be moved to -dev mailinglist.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] split GRASS (lib / cli / modules / wx / qt / web / etc.)

[Rainer M Krug]

Pietro  writes:

> Dear devs,
>
> stimulated by the GSOC idea of Ondřej I would like to revive again this topic.
> I know that this has been already discussed in the past, I found this
> (CLI1=GUI [0]) but it is focused on users and packagers prospective.
> Here I would like to face this point from a developer point of view.
> As point out in previous threads GRASS it is already modular, but
> (imho) there is duplicate code/functionalities and often things and
> levels are mixed.
>
> Let's start with a simple example: most of the GRASS modules, mix
> nicely logic and cli, several of them have a single main function with
> everything inside. I think could be useful to have a more clear
> distinction between logic/algorithms and their public interface
> (cli/gui). If we clearly split these two things the GRASS modules
> became just an interface to some functions inside the GRASS libraries.
>
> Another example is GRASS GUI that have internally a lot of
> functionalities that (imho) should be moved|integrated to a
> dedicated|existing python library, because their are independent by
> the library (wx|qt|javascript+html5) used to render the final GUI, and
> again to me it seems that a lot of things are mixed.
>
> Split these main functionalities in different repository can help
> developers, because they can focus/work on a smaller base of code.
>
> So how to split GRASS. It  would be nice to open a dedicate repository
> (git?) for each of this projects:
>
> - grass-lib: provides only C and Python API. This component should be
> a python citizen, I mean that should be available at the PyPI - the
> Python Package Index [1] and of course install-able as python package
> through pip;
> - grass-cli: provides a shell (with no modules!), also available as a
> pure python package;
> - grass-modules: provides all the GRASS core modules (this could be
> also a pure python interface calling functions in the C/Python
> libraries), and could be split in other sub categories (e.g. imagery,
> temporal, terrain, etc).
> - grass-wx: provides a WxPython/Phoenix interface for GRASS
> - (grass-qt: provides a PyQt/PySide interface for GRASS)
> - (grass-jupyther: provides a Jupyther interface to GRASS)
> - (grass-rest: provides a RESTful API for GRASS)
> - (add your idea here... :-D)
> - etc.
>
> Each point is characterize by a different use-case and this things are
> generally developed by different person with different backgrounds and
> needs and to me it make sense to split them.
>
> We could have a greater granularity and a clear focus for each
> repository and could help to acquire new developers because it open
> new GRASS' development possibilities.
> Enlarging the use-case of GRASS. Separate things in dedicated
> repository force developers to respect the distinction, and force them
> to think where the code should be put/published.
> Such subdivision could help has to reduce the total amount of code
> making things more general and abstract. It should also help making
> independent and well isolated tests.
>
>
> It should also help the development cycle since we can release things
> in a independently way, it requires only to specify in the
> requirements.txt file a working tested combinations of python packages
> versions.
>
> {{{
> numpy>=1.10
> grass-lib>=8
> grass-cli==8.1
> grass-modules>=8
> grass-wx=8.1.3
> }}}
>
> I think this idea could help mainly developers making things clear and
> well organized in different sub-projects.
> Opening the possibility to integrate GRASS functionalities to other
> open-source projects.
>
> This solution could help also in making things easier also for
> packager and users, for example users could install GRASS on all the
> system (win/Mac/*nix) running a single command:
>
> {{{
> $ pip install --user grass-lib grass-cli grass-modules grass-wx
> }}}
>
> What do you think?

I am not a developer of GRASS but in my experience, it is very
advantageous to split one large package into smaller ones and I think
this is definitely a step into the right direction.

Just for clarifications: GRASS will still be available as a deb package
for Debian and derivatives, dmg, ... I hope? (pip makes me always a
little bit nervous - no idea why. Possibky it is another package manager
in addition to deb, rpm, dmg, homebrew, Macports, ...).

Also: It would see it as very important that grass can be installed on
all systems (as you mention - win, mac, *nix, ...?).

Cheers,

Rainer

>
> All the best.
>
> Pietro
>
> [0] https://lists.osgeo.org/pipermail/grass-dev/2010-November/052661.html
> [1] https://pypi.python.org/pypi
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org

Re: [GRASS-dev] Interest in GSoC 2016

[Rainer M Krug]

Pietro  writes:

> Hi Ondřej,
>
> On Thu, Mar 17, 2016 at 7:45 PM,   wrote:
>> My idea was to generalize GUI Code for Qt-based GUI. Nowadays, Qt (PyQt) is
>> increasingly used (look at QGis, for example) and I think it would be better
>> to have minimally the roots of GUI in Qt. It’s also much easier to maintain
>> with new features. Work with design is also much more user-friendly. It
>> seems that in the future, it can be nice shortcut to change something in the
>> GUI.
>
> I like the idea, and I think could be strategic for the long run,
> especially because it is not clear to me if and when Phoenix (the
> wxPython for python3) will be ready (and from my superficial
> understanding of the GRASS problem on OS X El Captain Wx it seems part
> of the issue),

With my limited grasp of the grass internals and wxpython:

The main issue For El Capitan is the use of DYNLD_LIBRARY_PATH when
running binaries in /usr/bin or /bin directories (e.g. make). In the
case of homebrew (presumibly Macports as well), during compilation (I
can turn of SIP (System Integrity Progtection) on El Capitan, compile and
install, and enable it again, and it works) and in the case of the
binary compilation and running (as GRASS uses the shell which is in 
/usr/local/bin).

> instead both pyQt and pySide support python3 (I think
> we should build a GUI compatible with both binding. Consider that
> GRASS is already working with Python3 (with except of the ctype stuff)
> what it is critical (imho) it is the GUI.
>
> I do like the idea of Vaclav to share a core of functionalities of the
> GUI (between Wx, Qt, Jupyhter, etc). This shared functionalities
> should go in /lib/python/grass/{gui|somethingelse}. This should allow
> us to reduce duplication and the number of code that must be
> maintained.
>
> I think that we should also consider to split GRASS and its
> functionalities, but I open a separate thread on this.
>
> Best regards
>
> Pietro
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] split GRASS (lib / cli / modules / wx / qt / web / etc.)

[Pietro]

Dear devs,

stimulated by the GSOC idea of Ondřej I would like to revive again this topic.
I know that this has been already discussed in the past, I found this
(CLI1=GUI [0]) but it is focused on users and packagers prospective.
Here I would like to face this point from a developer point of view.
As point out in previous threads GRASS it is already modular, but
(imho) there is duplicate code/functionalities and often things and
levels are mixed.

Let's start with a simple example: most of the GRASS modules, mix
nicely logic and cli, several of them have a single main function with
everything inside. I think could be useful to have a more clear
distinction between logic/algorithms and their public interface
(cli/gui). If we clearly split these two things the GRASS modules
became just an interface to some functions inside the GRASS libraries.

Another example is GRASS GUI that have internally a lot of
functionalities that (imho) should be moved|integrated to a
dedicated|existing python library, because their are independent by
the library (wx|qt|javascript+html5) used to render the final GUI, and
again to me it seems that a lot of things are mixed.

Split these main functionalities in different repository can help
developers, because they can focus/work on a smaller base of code.

So how to split GRASS. It  would be nice to open a dedicate repository
(git?) for each of this projects:

- grass-lib: provides only C and Python API. This component should be
a python citizen, I mean that should be available at the PyPI - the
Python Package Index [1] and of course install-able as python package
through pip;
- grass-cli: provides a shell (with no modules!), also available as a
pure python package;
- grass-modules: provides all the GRASS core modules (this could be
also a pure python interface calling functions in the C/Python
libraries), and could be split in other sub categories (e.g. imagery,
temporal, terrain, etc).
- grass-wx: provides a WxPython/Phoenix interface for GRASS
- (grass-qt: provides a PyQt/PySide interface for GRASS)
- (grass-jupyther: provides a Jupyther interface to GRASS)
- (grass-rest: provides a RESTful API for GRASS)
- (add your idea here... :-D)
- etc.

Each point is characterize by a different use-case and this things are
generally developed by different person with different backgrounds and
needs and to me it make sense to split them.

We could have a greater granularity and a clear focus for each
repository and could help to acquire new developers because it open
new GRASS' development possibilities.
Enlarging the use-case of GRASS. Separate things in dedicated
repository force developers to respect the distinction, and force them
to think where the code should be put/published.
Such subdivision could help has to reduce the total amount of code
making things more general and abstract. It should also help making
independent and well isolated tests.


It should also help the development cycle since we can release things
in a independently way, it requires only to specify in the
requirements.txt file a working tested combinations of python packages
versions.

{{{
numpy>=1.10
grass-lib>=8
grass-cli==8.1
grass-modules>=8
grass-wx=8.1.3
}}}

I think this idea could help mainly developers making things clear and
well organized in different sub-projects.
Opening the possibility to integrate GRASS functionalities to other
open-source projects.

This solution could help also in making things easier also for
packager and users, for example users could install GRASS on all the
system (win/Mac/*nix) running a single command:

{{{
$ pip install --user grass-lib grass-cli grass-modules grass-wx
}}}

What do you think?

All the best.

Pietro

[0] https://lists.osgeo.org/pipermail/grass-dev/2010-November/052661.html
[1] https://pypi.python.org/pypi
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] FOSS4G 2016 - Call for Submissions!

[Markus Neteler]

On Mar 17, 2016 4:47 PM, "Luca Delucchi"  wrote:
>
> On 3 February 2016 at 09:52, Luca Delucchi  wrote:
> > Is someone thinking to submit GRASS GIS workshop?
> >
>
> any news? monday is the deadline for submission... we should present
> at least a workshop and a talk

I'm happy to propose a workshop.

Markus

> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] FOSS4G 2016 - Call for Submissions!

[Luca Delucchi]

On 17 March 2016 at 18:52, Markus Neteler  wrote:
>
>
> I'm happy to propose a workshop.
>

I can help you...

> Markus
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Markus Neteler]

Hi,

I just needed r.rgb and found the script broken: must be a silly bug
but I don't see it..:

# NC

GRASS 7.1.svn (nc_spm_08_grass7): > r.rgb input=elevation

syntax error, unexpected $end, expecting VARNAME or NAME or STRING
Parse error
ERROR: parse error
ERROR: An error occurred while running r.mapcalc

Any idea?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] changes in r.in.aster

[Vaclav Petras]

On Wed, Mar 16, 2016 at 12:30 PM, Carlos Grohmann  wrote:

> 3 - This line was giving me errors:
> if platform.system() == "Darwin":
> cmd = ["arch", "-i386", "gdalwarp", "-t_srs", proj, srcfile,
> tempfile ]
>
> arch: posix_spawnp: gdalwarp: Bad CPU type in executable
>
>
> This is probably because I run OSC El Cap, which is 64bits. So to get it
> working, I had to ignore this system test and use
>
> cmd = ["gdalwarp", "-t_srs", proj, srcfile, tempfile ]
>
> Nut I'm not sure what would be the best way to keep the test and maintain
> compatibility with older systems. Perhaps a try/except would do.
>

Try/except sounds like a good solution which is also Pythonic. I think you
should keep if statement there (inside the except).

Here is the history of the file [1, 2]. Perhaps Michael can comment on
whether this check makes even sense now. It is a distribution issue, so if
we can avoid solving it in the source code, it will be good.

Vaclav

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/scripts/r.in.aster/r.in.aster.py?annotate=blame
[2] https://trac.osgeo.org/grass/changeset/32178
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OSGeo-SoC 2016 application

[Luca Delucchi]

On 16 March 2016 at 04:49, Yang, Bo (yangb2)  wrote:
> Hi Luca,
>

Hi Bo Yang,

> Thank you for the reply and info. It is great if you could co-mentor this 
> project. I would be more interest in implementing my spatio-temporal fusion 
> algorithm as an open source plug-in. Actually, I already have the preliminary 
> python code for the raster fusion, including modules of spatio-temporal 
> semi-variogram calculating, exponential/Gaussian fitting, spatio-temporal 
> fusion, uncertainty estimation and etc. Currently it runs well for fusing 
> MODIS and Landsat data. But it is just a preliminary program, I think a lot 
> more works need to be done to make it professional and could incorporated 
> into GRASS framework.

Could we see and test the code? I'm interesting to test it with MODIS data...

> I've read the link you sent to me. I think it is a good point to add it to 
> r.series.interp, which I noticed author is Sören Gebbert. Should I ask Sören 
> if he is interested to be a potential mentor? Furthermore, could you advise 
> what should I do now to get start for the programming environmental as well 
> as prepare the proposal?
>

Yes, I think you should ask Soeren, he knows a lot about this topic.
You have to compile GRASS [0], do you have a Windows or Unix OS?
After this you can start to read more about GRASS programming [1]

> Best,
> Bo Yang
>

[0] https://grasswiki.osgeo.org/wiki/Compile_and_Install
[1] https://grass.osgeo.org/programming7/

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.rgb: syntax error, unexpected $end, expecting VARNAME or NAME or STRING

[Glynn Clements]

Vaclav Petras wrote:

> > ok. But another error occurs (missing error handling if the output
> > names were selected to be identica):
> > ...
> > Perhaps there is an elegant solution to catch the (user) error above?
> 
> Isn't this an issue for every module? I'm not sure if we have a general
> solution (as in the previous case).

Most modules won't explicitly complain if you use the same map name
for multiple outputs, although it's anyone's guess as to what actually
ends up in the map.

I'm reasonably sure that the primary files (cellhd, cell/fcell, null,
f_{format,quant,range} etc) will be consistent, but metadata files
which are written separately (colour table, categories, history, etc)
may be from a different output.

The fact that r.rgb.py fails in this case is really just a
coincidence. It won't complain about using the same name for all
outputs, only for the case where one of the outputs matches the input. 

The error arises because, in r.mapcalc, using a name on the left-hand
side of an assignment causes the name to be interpreted as a variable
rather than as a map, and the r#/g#/b# modifiers can only be applied
to maps, not variables.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

[GRASS GIS]

#2296: r.stream.* - unify some functions (avoid code duplication)
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  major|  Milestone:  7.0.4
 Component:  Addons   |Version:  svn-trunk
Resolution:   |   Keywords:  r.stream.*
   CPU:  All  |   Platform:  All
--+-

Comment (by mlennert):

 Can this be closed ?

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2705: r.clump maintain original categories

[GRASS GIS]

#2705: r.clump maintain original categories
--+
  Reporter:  lucadelu |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  major|  Milestone:  7.0.4
 Component:  Raster   |Version:  unspecified
Resolution:  invalid  |   Keywords:  r.clump classification
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 As there hasn't been any reaction from the OP, and I agree with Maris'
 remark, I'm taking the freedom to close this bug.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2964: G7: v.extract does not remove islands

[GRASS GIS]

#2964: G7: v.extract does not remove islands
--+---
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Vector   |Version:  7.0.3
Resolution:   |   Keywords:  v.extract,islands
   CPU:  Unspecified  |   Platform:  All
--+---

Comment (by mmetz):

 Replying to [ticket:2964 sbl]:
 > v.extract in GRASS 7.0.3 (and trunk too I guess) does not remove islands
 from areas.

 This is correct behaviour of v.extract. In GRASS, an area is composed of
 boundaries of the outer ring and boundaries of the enclosed islands, and a
 centroid. If you extract a given area with v.extract, you get its
 boundaries of the outer ring, boundaries of any enclosed islands, and its
 centroid. This is identical to non-topological vectors like shapefiles: a
 polygon is defined by its outer ring and any inner rings (islands).
 Extracting a single polygon will preserve the inner rings but not the
 polygons inside the inner rings.
 >
 > {{{
 > # From the Manual
 > v.extract input=map_with_islands output=maps_without_islands
 cats=1-9
 > # and/or
 > v.extract -d in=map_with_islands out=maps_without_islands
 > }}}

 The manual is misleading because it does not specify the type to be
 extracted (should be area) and because it does not specify the layer to be
 extracted (presumably 1). The manual is wrong because the given commands
 do not remove islands. They are not supposed to remove islands, or inner
 rings in Simple Feature Specification.

 Manuals of relbr70 and trunk have been updated in r68070,1.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev