date:20140520

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

2014-05-20 Thread Markus Neteler

On Mon, May 19, 2014 at 3:08 PM, Glynn Clements
 wrote:
...
> Fixed in r60345.
...
> r60346 implements the following logic:

My tests went fine so far, any objections that I sync the r.neighbors
version in relbr7 to trunk?

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

Re: [GRASS-dev] [GRASS-SVN] r60385 - grass/branches/releasebranch_7_0/gui/wxpython/mapwin

2014-05-20 Thread Markus Neteler

Hi,

could d.rast.leg somehow leverage below "library" code? At time it is
suboptimal in placing the legend next to a raster map while being
generally very handy for cmd line junkies...

thanks
Markus

On Wed, May 21, 2014 at 5:07 AM,   wrote:
> Author: annakrat
> Date: 2014-05-20 20:07:17 -0700 (Tue, 20 May 2014)
> New Revision: 60385
>
> Modified:
>grass/branches/releasebranch_7_0/gui/wxpython/mapwin/decorations.py
> Log:
> wxGUI/legend: change default legend position so that legend histogram is not 
> cut off (merge from trunk, r60384)
>
> Modified: grass/branches/releasebranch_7_0/gui/wxpython/mapwin/decorations.py
> ===
> --- grass/branches/releasebranch_7_0/gui/wxpython/mapwin/decorations.py 
> 2014-05-21 03:06:27 UTC (rev 60384)
> +++ grass/branches/releasebranch_7_0/gui/wxpython/mapwin/decorations.py 
> 2014-05-21 03:07:17 UTC (rev 60385)
> @@ -211,7 +211,7 @@
>  self._id = 0
>  self._name = 'legend'
>  # TODO: synchronize with d.legend?
> -self._defaultAt = 'at=5,50,2,5'
> +self._defaultAt = 'at=5,50,7,10'
>  self._cmd = ['d.legend', self._defaultAt]
>
>  def GetPlacement(self, screensize):
>
> ___
> grass-commit mailing list
> grass-com...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-commit
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2201: Introduce 'do not create attribute table' flag to r.contour

2014-05-20 Thread GRASS GIS

#2201: Introduce 'do not create attribute table' flag to r.contour
+---
 Reporter:  wenzeslaus  |   Owner:  grass-dev@… 
 
 Type:  enhancement |  Status:  new 
 
 Priority:  minor   |   Milestone:  7.0.0   
 
Component:  Raster  | Version:  unspecified 
 
 Keywords:  r.contour, attribute table, parameters  |Platform:  All 
 
  Cpu:  All |  
+---

Comment(by annakrat):

 Flag -t implemented in r60381. Just to make sure I will backport it after
 a few days.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2302: water/hydrology related modules: harmonize/standardize terms over modules

2014-05-20 Thread GRASS GIS

#2302: water/hydrology related modules: harmonize/standardize terms over modules
--+-
 Reporter:  hellik|   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.1.0
Component:  Raster| Version:  unspecified  
 Keywords:  raster, hydrology, water  |Platform:  All  
  Cpu:  All   |  
--+-
 GRASS GIS includes a lot of water/hydrology related modules.

 it would be nice to harmonize/standardize terms over modules.

 e.g.

 [http://grass.osgeo.org/grass71/manuals/r.stream.extract.html
 r.stream.extract]

 {{{
 r.stream.extract - Performs stream network extraction.

 threshold=float [required]
 Minimum flow accumulation for streams
 Must be > 0
 }}}

 [http://grass.osgeo.org/grass71/manuals/r.watershed.html r.watershed]

 {{{
 r.watershed - Calculates hydrological parameters and RUSLE factors.

 threshold=integer
 Minimum size of exterior watershed basin
 }}}

 AFAIU threshold is basically a value of flow accumulation.

 there may be a lot of other terms which should be  harmonized/standardized

-- 
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] #2296: r.stream.* - unify some functions (avoid code duplication)

2014-05-20 Thread GRASS GIS

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

  * milestone:  7.0.0 => 7.1.0


-- 
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] #2296: r.stream.* - unify some functions (avoid code duplication)

2014-05-20 Thread 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.0
Component:  Raster   | Version:  svn-trunk
 Keywords:  r.stream.*   |Platform:  All  
  Cpu:  All  |  
-+--

Comment(by hellik):

 Replying to [comment:2 hellik]:
 >
 > worth to open a new ticket?

 opened a new ticket, see #2301

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2301: unifying all of the different "segment" libraries

2014-05-20 Thread GRASS GIS

#2301: unifying all of the different "segment" libraries
-+--
 Reporter:  hellik   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Raster   | Version:  svn-trunk
 Keywords:   |Platform:  All  
  Cpu:  All  |  
-+--
 quoting here comment 1 in ticket #2296
 ([http://trac.osgeo.org/grass/ticket/2296#comment:1 unifying segment
 libraries])

 {{{
  While we're at it, maybe we should look into unifying all of the
 different "segment" libraries.

 They all do essentially the same thing: provide a 2-dimensional array
 which may be too large to fit into RAM (or, more accurately, into the
 process' address space; if RAM was the issue, mmap() etc would suffice),
 and which can be accessed (more or less) randomly.

 Apart from the "official" segment library (lib/segment), r.proj has its
 own, r.stream.* each have their own, r.grow.distance has something simpler
 (the temporary file is read row-by-row but in reverse).
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Python Higher Level Libs

2014-05-20 Thread Sören Gebbert

Hi Nick,
do you plan to implement something like this[1]?

[1] http://www.mdpi.com/2220-9964/2/1/201/pdf

Best regards
Soeren

2014-05-20 19:26 GMT+02:00 Nick Ves :
> Dear All,
>
>
> I'd like to pitch the idea for the creation of higher level modules
> for easier access to raster characterists.
>
> The module could be used for standarazation of python scripts and
> enabling users to rapid protorype their ideas.
>
> I think the underling infrastructure is there for the creating at
> least a very simple prototype.
>
>
> I'd like to hear your views on the subject
>
> N
> ___
> 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] Python Higher Level Libs

2014-05-20 Thread Nick Ves

Dear All,


I'd like to pitch the idea for the creation of higher level modules
for easier access to raster characterists.

The module could be used for standarazation of python scripts and
enabling users to rapid protorype their ideas.

I think the underling infrastructure is there for the creating at
least a very simple prototype.


I'd like to hear your views on the subject

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

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

2014-05-20 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| Version:  unspecified
Resolution:  fixed|Keywords:  region 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-

Comment(by annakrat):

 Backported in r60377.

-- 
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-SVN] r60376 - grass/trunk/gui/wxpython/core

2014-05-20 Thread Anna Petrášová

Hi,

I committed a change to rendering which could help to run d.mon and wxGUI
together. The environment is changed only for the rendering process and not
for the entire wxGUI. There is a lot of other places which should be
changed like this but the rendering is the most important. Please test, I
tried to test it already (d.mon, wms, georectifier) but more testing is
still needed.

Anna


On Tue, May 20, 2014 at 11:14 AM,  wrote:

> Author: annakrat
> Date: 2014-05-20 08:14:42 -0700 (Tue, 20 May 2014)
> New Revision: 60376
>
> Modified:
>grass/trunk/gui/wxpython/core/render.py
>grass/trunk/gui/wxpython/core/ws.py
> Log:
> wxGUI/rendering: change environment only for subprocesses; wxGUI amd d.mon
> should now work together
>
> Modified: grass/trunk/gui/wxpython/core/render.py
> ===
> --- grass/trunk/gui/wxpython/core/render.py 2014-05-20 14:55:52 UTC
> (rev 60375)
> +++ grass/trunk/gui/wxpython/core/render.py 2014-05-20 15:14:42 UTC
> (rev 60376)
> @@ -86,10 +86,11 @@
>  self.renderMgr = None
>
>  self.Map = Map
> -self.type  = None
> +self.type = None
>  self.SetType(ltype)
> -self.name  = name
> -
> +self.name = name
> +self.environ = os.environ.copy()
> +
>  if self.type == 'command':
>  self.cmd = list()
>  for c in cmd:
> @@ -136,7 +137,7 @@
>   {'type' : self.type, 'name' : self.name
> })
>
>  if self.mapfile:
> -os.environ["GRASS_PNGFILE"] = self.mapfile
> +self.environ["GRASS_PNGFILE"] = self.mapfile
>
>  # execute command
>  try:
> @@ -147,9 +148,9 @@
>  if ret != 0:
>  break
>  if not read:
> -os.environ["GRASS_PNG_READ"] = "TRUE"
> +self.environ["GRASS_PNG_READ"] = "TRUE"
>
> -os.environ["GRASS_PNG_READ"] = "FALSE"
> +self.environ["GRASS_PNG_READ"] = "FALSE"
>  else:
>  ret, msg = self._runCommand(self.cmd)
>  if ret != 0:
> @@ -165,11 +166,7 @@
>  continue
>  grass.try_remove(f)
>  f = None
> -
> -# stop monitor
> -if self.mapfile and "GRASS_PNGFILE" in os.environ:
> -del os.environ["GRASS_PNGFILE"]
> -
> +
>  self.forceRender = False
>
>  return self.mapfile
> @@ -180,11 +177,12 @@
>  if self.type == 'wms':
>  ret = 0
>  msg = ''
> -self.renderMgr.Render(cmd)
> +self.renderMgr.Render(cmd, env=self.environ)
>  else:
>  ret, msg = RunCommand(cmd[0],
>getErrorMsg = True,
>quiet = True,
> +  env=self.environ,
>**cmd[1])
>
>  return ret, msg
> @@ -301,6 +299,10 @@
>  # for re-rendering
>  self.forceRender = True
>
> +def SetEnvironment(self, environ):
> +"""!Sets environment for rendering."""
> +self.environ = environ
> +
>  def IsDownloading(self):
>  """!Is data downloading from web server e. g. wms"""
>  if self.renderMgr is None:
> @@ -385,10 +387,7 @@
>
>  self.overlays  = list()  # stack of available overlays
>  self.ovlookup  = dict()  # lookup dictionary for overlay items
> and overlays
> -
> -# environment settings
> -self.env   = dict()
> -
> +
>  # path to external gisrc
>  self.gisrc = gisrc
>
> @@ -396,7 +395,6 @@
>  self.mapfile = grass.tempfile(create = False) + '.ppm'
>
>  # setting some initial env. variables
> -self._initGisEnv() # g.gisenv
>  if not self.GetWindow():
>  sys.stderr.write(_("Trying to recover from default
> region..."))
>  RunCommand('g.region', flags='d')
> @@ -405,16 +403,12 @@
>  self.progressInfo = None
>
>  # GRASS environment variable (for rendering)
> -self.env = {"GRASS_BACKGROUNDCOLOR" : "00",
> -   "GRASS_PNG_COMPRESSION" : "0",
> -   "GRASS_TRUECOLOR"   : "TRUE",
> -   "GRASS_TRANSPARENT" : "TRUE",
> -   "GRASS_PNG_READ": "FALSE",
> -   }
> +self.default_env = {"GRASS_BACKGROUNDCOLOR" : "00",
> +"GRASS_PNG_COMPRESSION" : "0",
> +"GRASS_TRUECOLOR"   : "TRUE",
> +"GRASS_TRANSPARENT" : "TRUE"
> +}
>
> -for k, v in self.env.iteritems():
> -os.environ[k] = v
> -
>  # projection info
>  self.projinfo = self._projInfo()
>
> @@ -424,30 +418,6 @@
>  self.layerChanged = Signal('Map.la

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

2014-05-20 Thread Martin Landa

2014-05-20 16:57 GMT+02:00 Markus Neteler :
> On Mon, May 19, 2014 at 4:49 PM, Martin Landa  wrote:
>> 2014-05-19 15:08 GMT+02:00 Glynn Clements :
>>> r60346 implements the following logic:
>>>
>>> For any aggregate, there are 2 factors affecting the output type:
> ...
>> would be nice to put to the manual I guess. Martin
>
> I have taken liberty to add Glynn's comments in r60375 to the manual.

thanks! 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] G7: r.neighbors changes data type from CELL to DCELL

2014-05-20 Thread Markus Neteler

On Mon, May 19, 2014 at 4:49 PM, Martin Landa  wrote:
> 2014-05-19 15:08 GMT+02:00 Glynn Clements :
>> r60346 implements the following logic:
>>
>> For any aggregate, there are 2 factors affecting the output type:
...
> would be nice to put to the manual I guess. Martin

I have taken liberty to add Glynn's comments in r60375 to the manual.

Markus

PS: Yes, even checked HTML with http://validator.w3.org/ :-)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

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

2014-05-20 Thread GRASS GIS

#1628: segfault in r.walk
+---
 Reporter:  pertusus|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  Raster  | Version:  svn-releasebranch64  
 Keywords:  r.cost, r.walk  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by mlennert):

 Replying to [comment:5 glynn]:
 > Replying to [comment:3 mlennert]:
 >
 > > I do not have the time right now to check if this is linked to a
 specific attribute or just the general number of attributes, but maybe
 someone else can continue on that path ?
 >
 > Could it be a problem with lib/sites?

 It would seem a likely candidate, but how would that influence what is
 happening a long time after the closure of the input file ? The segfault
 occurs in the routine finding the cost path in which, AFAICT, the
 lib/sites doesn't play a role anymore.

-- 
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] #2031: G_legal_filename() cleanup patch for GRASS 6

2014-05-20 Thread GRASS GIS

#2031: G_legal_filename() cleanup patch for GRASS 6
--+-
  Reporter:  neteler  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  LibGIS   | Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:   
  Platform:  All  | Cpu:  All  
--+-

Comment(by glynn):

 Replying to [comment:12 mlennert]:

 > Legitimate question: it seems to me that r32820 mixes cases where the
 output are (non-GRASS element) files (e.g. r.kappa) with cases where the
 output are GRASS element files (e.g. r.buffer, r.median, r.neighbors). Why
 was the change necessary/advisable for the latter ?

 G!__open_raster_new() accepts a fully-qualified name for an output map, so
 long as the mapset matches the current mapset. G!__open_raster_new()
 performs this check, removes any @mapset part, then performs the
 G_legal_filename() check on the unqualified name.

 So a G_legal_filename() call in the module is typically redundant (the
 open_new function will reject invalid names soon enough), and will reject
 qualified names which may otherwise work fine. I say "may" because I don't
 know whether the functions for writing support files (history, colour
 tables, etc) also cope with qualified names.

 If the G_legal_filename() calls are required to protect functions other
 than G_open_*_new(), they should remain. Otherwise, they should be
 removed.

 In 7.x, the library functions are quite consistent about accepting
 qualified names. Modules should normally be able to pass names from option
 values straight through to library functions without any checks or
 parsing. The only cases which are problematic are where an option
 specifies a base name to which a suffix is appended (i.e. you need to
 generate map.suffix@mapset, while simply appending the suffix will produce
 map@mapset.suffix), modules which explicitly deal with mapsets or
 locations (e.g. r.proj), or database-management utilities (e.g. g.mlist).

 Having said that, it would have been better if r32820 had been split into
 separate patches, one to remove bogus checks (e.g. names of non-GRASS data
 files) and another to remove redundant checks.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

2014-05-20 Thread Glynn Clements

Blumentrath, Stefan wrote:

> >r60346 implements the following logic:
> 
> >For any aggregate, there are 2 factors affecting the output type:
> 
> >1. Whether the input map is integer or floating-point.
> >2. Whether the weighted or unweighted version of the aggregate is used.
> 
> Out of curiosity, could this logic also be applied to r.resamp.stats?
> Or did this module already receive a similar solution?

r.resamp.stats always generates DCELL output.

In theory, the same logic could be used for anything which uses
lib/stats, i.e. r.neighbors, r.resamp.stats, r.series,
r.series.interp, r3.neighbors, and v.vect.stats.

Some of those only use the unweighted methods, in which case the logic
would be simpler.

v.vect.stats has the output type dictated by the type of the output
column. However, each method has a flag to indicate whether conversion
to integer should use truncation or rounding. Rounding is used for
methods which can return non-integer results for integer data.

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

Re: [GRASS-dev] [GRASS GIS] #2298: r.stream.order hack= generates order 1 single pixels

2014-05-20 Thread GRASS GIS

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hellik):

 Replying to [comment:5 hellik]:
 > Replying to [hcho]:
 > > Unfortunately, accumulation map didn't help. I got the same result.
 Maybe, flow direction map is still used for calculating orders? and
 accumulation map is optional for doing something else...?
 >
 > what about your region settings? the region and resolution should be
 > aligned to the DEM, e.g. g.region -a rast=yourDEM align=yourDEM.

 tested here with different DEM (10x10m, 25x25m, 35x35m, 100x100m) and
 different thresholds for river extraction, can't reproduce the report.

 for the record, beside the region settings, the manual states:

 {{{
 The module can work only if direction map, stream_rast map and the
 computational region have the same settings. It is also required that the
 stream_rast map and the direction map come from the same source. For lots
 of reason this limitation probably cannot be omitted. This means if
 stream_rast map comes from r.stream.extract also the direction map from
 r.stream.extract must be used. If stream network was generated with MFD
 method also MFD direction map must be used.
 }}}

 regarding accumulation map:

 {{{
 Optional input flow accumulation map may be produced by r.watershed or
 r.stream.extract. This map is an option only if Horton's or Hack's
 ordering is performed. Normally both Horton and Hack ordering is
 calculated on cumulative stream length which is calculated internally.
 Flow accumulation can be used if user wants to calculate the main channel
 as the stream with the highest value of aqccumulation.
 }}}

-- 
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-SVN] r60310 - in grass/branches/releasebranch_7_0: . raster/r.colors

2014-05-20 Thread Glynn Clements


Huidae Cho wrote:

> Does that mean it's better to commit mergeinfo to avoid duplicate merges by
> mistake?

Yes.

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

Re: [GRASS-dev] [GRASS GIS] #2298: r.stream.order hack= generates order 1 single pixels

2014-05-20 Thread GRASS GIS

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hellik):

 Replying to [comment:4 hcho]:
 > Unfortunately, accumulation map didn't help. I got the same result.
 Maybe, flow direction map is still used for calculating orders? and
 accumulation map is optional for doing something else...?

 see:

 -a
 Use flow accumulation to trace horton and hack models

 did you use this flag when accumulation map is used as input?

-- 
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] #2277: graphically set up region bounds

2014-05-20 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| Version:  unspecified
Resolution:  fixed|Keywords:  region 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-

Comment(by mlennert):

 Replying to [comment:21 annakrat]:

 > Apparently the -a flag requires the resolution parameter to be applied.
 Please try r60300.


 Works great, thanks !

 Moritz

-- 
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] #2031: G_legal_filename() cleanup patch for GRASS 6

2014-05-20 Thread GRASS GIS

#2031: G_legal_filename() cleanup patch for GRASS 6
--+-
  Reporter:  neteler  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  LibGIS   | Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:   
  Platform:  All  | Cpu:  All  
--+-

Comment(by mlennert):

 Replying to [comment:11 neteler]:
 > Replying to [comment:10 hamish]:
 > > r6,1 need to be reverted.
 >
 > Feel free to revert. But please explain shortly why
 >
 > r32820 "G_legal_filename() is for files, not maps"
 >
 > should not be reverted, too.

 Legitimate question: it seems to me that r32820 mixes cases where the
 output are (non-GRASS element) files (e.g. r.kappa) with cases where the
 output are GRASS element files (e.g. r.buffer, r.median, r.neighbors). Why
 was the change necessary/advisable for the latter ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

2014-05-20 Thread Paulo van Breugel

Thanks, I know (I read) how to do this, but wasn't sure it is actually 
working with GRASS 7. Happy to hear at least somebody managed :-).  I 
will give it a try then.



On 05/20/2014 10:25 AM, Markus Neteler wrote:

On Tue, May 20, 2014 at 9:11 AM, Blumentrath, Stefan
 wrote:

Hei Paolo,



This is the relevant GDAL ticket:

http://trac.osgeo.org/gdal/ticket/2953



The GRASS plugin on http://download.osgeo.org/gdal/ has not been updated
yet, but in the meantime you can rebuild GDAL against GRASS 7.

Workflow would be:

Build GDAL 1.11 without GRASS Support

Build GRASS (7) against GDAL 1.11

Build GDAL 1.11 with GRASS 7 support

You find that documented also here:

http://grasswiki.osgeo.org/wiki/Compile_and_install_GDAL-GRASS_plugin

Markus


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

Re: [GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

2014-05-20 Thread Markus Neteler

On Tue, May 20, 2014 at 9:11 AM, Blumentrath, Stefan
 wrote:
> Hei Paolo,
>
>
>
> This is the relevant GDAL ticket:
>
> http://trac.osgeo.org/gdal/ticket/2953
>
>
>
> The GRASS plugin on http://download.osgeo.org/gdal/ has not been updated
> yet, but in the meantime you can rebuild GDAL against GRASS 7.
>
> Workflow would be:
>
> Build GDAL 1.11 without GRASS Support
>
> Build GRASS (7) against GDAL 1.11
>
> Build GDAL 1.11 with GRASS 7 support

You find that documented also here:

http://grasswiki.osgeo.org/wiki/Compile_and_install_GDAL-GRASS_plugin

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

Re: [GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

2014-05-20 Thread GRASS GIS

#2031: G_legal_filename() cleanup patch for GRASS 6
--+-
  Reporter:  neteler  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.4
 Component:  LibGIS   | Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:   
  Platform:  All  | Cpu:  All  
--+-

Comment(by neteler):

 Replying to [comment:10 hamish]:
 > r6,1 need to be reverted.

 Feel free to revert. But please explain shortly why

 r32820 "G_legal_filename() is for files, not maps"

 should not be reverted, too.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

2014-05-20 Thread Blumentrath, Stefan

Hei Paolo,

This is the relevant GDAL ticket:
http://trac.osgeo.org/gdal/ticket/2953

The GRASS plugin on http://download.osgeo.org/gdal/ has not been updated yet, 
but in the meantime you can rebuild GDAL against GRASS 7.
Workflow would be:
Build GDAL 1.11 without GRASS Support
Build GRASS (7) against GDAL 1.11
Build GDAL 1.11 with GRASS 7 support

Using that workflow, GDAL managed to read GRASS 7 raster data on my Ubuntu 
12.04 LTS Server. However, I am not sure if the fixes by hcho have been merged 
into the 1.11 release (or the latest code yet). So maybe reading GRASS data 
using only GDAL could give incorrect results (incorrect window read?)...
Others please correct me if I am wrong...



Cheers
Stefan

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

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

Re: [GRASS-dev] [GRASS-SVN] r60385 - grass/branches/releasebranch_7_0/gui/wxpython/mapwin

Re: [GRASS-dev] [GRASS GIS] #2201: Introduce 'do not create attribute table' flag to r.contour

[GRASS-dev] [GRASS GIS] #2302: water/hydrology related modules: harmonize/standardize terms over modules

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

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

[GRASS-dev] [GRASS GIS] #2301: unifying all of the different "segment" libraries

Re: [GRASS-dev] Python Higher Level Libs

[GRASS-dev] Python Higher Level Libs

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

Re: [GRASS-dev] [GRASS-SVN] r60376 - grass/trunk/gui/wxpython/core

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

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

Re: [GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

Re: [GRASS-dev] [GRASS GIS] #2298: r.stream.order hack= generates order 1 single pixels

Re: [GRASS-dev] [GRASS-SVN] r60310 - in grass/branches/releasebranch_7_0: . raster/r.colors

Re: [GRASS-dev] [GRASS GIS] #2298: r.stream.order hack= generates order 1 single pixels

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

Re: [GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

Re: [GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

Re: [GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

Re: [GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

Re: [GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

25 matches

Site Navigation

Mail list logo

Footer information