Re: [GRASS-dev] [GRASS GIS] #1775: v.surf.rst does not respect mask

[GRASS GIS]

#1775: v.surf.rst does not respect mask
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:  v.surf.rst   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by bhlevca):

 Replying to [comment:7 cmbarton]:
 > Replying to [comment:6 neteler]:
 > > Also in my opinion it would be good to have a mask= parameter
 available for the other
 > > interpolation modules.
 >
 > I definitely agree!

 You would be surprised to know that in ArcGis only two interpolation modes
 (geoprocessing IDW and Kernel) can use a mask layer as a barrier. If GRASS
 achieve what Markus suggested it will have the upper hand in this domain.

-- 
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] #1775: v.surf.rst does not respect mask

[GRASS GIS]

#1775: v.surf.rst does not respect mask
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:  v.surf.rst   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 Replying to [comment:6 neteler]:
 > More generally:
 >
 > Also in my opinion it would be good to have a mask= parameter available
 for the other
 > interpolation modules.

 I definitely agree!

 >
 > See also the comment about v.surf.icw here:
 > http://gis.stackexchange.com/questions/85387/how-to-interpolate-a-point-
 vector-layer-inside-a-boundary-polygon-layer-qgis-g

-- 
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] #1775: v.surf.rst does not respect mask

[GRASS GIS]

#1775: v.surf.rst does not respect mask
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:  v.surf.rst   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 More generally:

 Also in my opinion it would be good to have a mask= parameter available
 for the other
 interpolation modules.

 See also the comment about v.surf.icw here:
 http://gis.stackexchange.com/questions/85387/how-to-interpolate-a-point-
 vector-layer-inside-a-boundary-polygon-layer-qgis-g

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Hamish]

Hamish wrote:

> e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing 
> anything wrt metadata that we could share development with?

see also deegree, qgis MetaSearch plugin, and the OSWLib library.


Hamish

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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Hamish]

Hi,

(thanks for the great ideas pages everyone: osgeo gsoc 2014 is accepted and 
happening!)


integrating an existing open source metadata library instead of starting from 
scratch would be faster and easier to maintain in
the long run. :)

e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing 
anything wrt metadata that we could share development with?



Hamish

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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Newcomb, Doug]

A good metadata tool that generates  ISO compliant xml  would be very
useful and a substantial accomplishment by itself.

Doug




On Mon, Feb 24, 2014 at 2:22 PM, Martin Landa wrote:

> Hi,
>
> 2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová :
> > finally I considered the metadata topic is probably the most appropriate
> for
> > me. My aim now is to find out as much as I can about it to have better
> idea
> > what is going on. If you have any additional information or resources I
> > could study, please let me know. Thanks
>
> perfect, in this regard I would like to open discussion whether to
> speak just about metadata (ISO, Inspire) or also about  supporting
> Inspire services (view and download)...
>
> Martin
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.clump4p - OpenMP version of r.clump

[Markus Metz]

On Mon, Feb 24, 2014 at 12:00 PM, Moritz Lennert
 wrote:
> On 23/02/14 23:10, Markus Metz wrote:
>>
>> There is an OpenMP version of r.clump available at
>>
>> http://sil.uc.edu/downloads.html#software
>>
>> called r.clump4p. The reported performance gain is 450 times over the
>> original r.clump.
>>
>> The performance gain over the original r.clump vanished:
>> r.clump4p with one thread is now about 12x slower than r.clump, and
>> r.clump4p with 4 threads is now about 5x slower than r.clump.
>> Moreover, the results of r.clump4p are wrong, it clumps together areas
>> with different cell values (no multithreading effect).

In my test area with 650 million cells and 17.6 million clumps, the
updated version of r.clump is now about 20x faster than r.clump4p (one
thread) and about 8x faster than r.clump4p (four threads). r.clump
always uses only one thread. In real time this is 3 minutes vs 1 hour.

>>
>> I tested in a region with 650 million cells, both modules produced
>> about 17.6 million clumps. All differences in the resultant clumps
>> were due to errors in r.clump4p.
>>
>> Tests were performed in GRASS 7 where I have optimized r.clump and
>> also added support for diagonal clump tracing.
>
>
> Great work ! Thanks a lot, Markus !
>
> Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Martin Landa]

Hi,

2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová :
> finally I considered the metadata topic is probably the most appropriate for
> me. My aim now is to find out as much as I can about it to have better idea
> what is going on. If you have any additional information or resources I
> could study, please let me know. Thanks

perfect, in this regard I would like to open discussion whether to
speak just about metadata (ISO, Inspire) or also about  supporting
Inspire services (view and download)...

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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Tereza Fiedlerová]

Hi,

finally I considered the metadata topic is probably the most appropriate
for me. My aim now is to find out as much as I can about it to have better
idea what is going on. If you have any additional information or resources
I could study, please let me know. Thanks

Tereza


On 20 February 2014 09:33, Margherita Di Leo wrote:

> Hi Tereza!
>
>
> On Thu, Feb 20, 2014 at 9:08 AM, Tereza Fiedlerová 
> wrote:
>>
>>
>> And one more question. Is any of these topics suitable for me if I am not
>> experienced in GRASS at all?
>>
>> Please consider the idea on metadata, that requires a limited knowledge
> of GRASS I would say
>
>
>
> --
> Best regards,
>
> Dr. Margherita DI LEO
> Scientific / technical project officer
>
> European Commission - DG JRC
> Institute for Environment and Sustainability (IES)
> Via Fermi, 2749
> I-21027 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
> Disclaimer: The views expressed are purely those of the writer and may not
> in any circumstance be regarded as stating an official position of the
> European Commission.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Suggestion about parameter 'size' in module r.param.scale

[Alessandro Samuel Rosa]

Dear GRASS developers,

The parameter 'size' in module r.param.scale defines the window size
used to calculate DEM derivatives. It has a fixed maximum value of 69
defined in the line 18 of the header file 'param.h'.  I suggest that
this value be changed to a somewhat higher value like 999 to allow the
user to employ larger windows to calculate DEM derivatives. The software
from which this module was derived (LandSerf) allows in its actual
version any window size.

Unfortunately I have no experience with Grass development to help
improve this module. I hope you can make this improvement.

Many thanks in advance.


-- 

Alessandro Samuel-Rosa
---
PhD Candidate Graduate School in Agronomy - Soil Science
Federal Rural University of Rio de Janeiro
Seropédica, Rio de Janeiro, Brazil
---
Guest Researcher ISRIC - World Soil Information
Wageningen, the Netherlands alessandro.r...@wur.nl
---
Homepage: soil-scientist.net Skype: alessandrosamuel 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Wxgui issue (probably due to non-standard python install)..

[Isaac Ullah]

Dear dev-list,

I've got an Ubuntu 12.04 workstation on which I have been experimenting
with python for scientific computing  (e.g.,  ipython notebook, spyder,
etc.). During this process, I experimented with a lot of different python
modules, installed variously with apt-get or with pip. Before this
experimentation, GRASS 6.4.3-1 (from Ubuntu GIS-unstable PPA) was working
just fine, but now I am getting the following error upon start of GRASS:

> wxnviz.py: This module requires the NumPy module, which could not be
imported. It probably is not installed (it's not part of the standard
Python distribution). See the Numeric Python site (http://numpy.scipy.org)
for information on downloading source or binaries.
Traceback (most recent call last):
  File "/usr/lib/grass64/etc/wxpython/wxgui.py", line 34, in 
from lmgr.frame import GMFrame
  File "/usr/lib/grass64/etc/wxpython/lmgr/frame.py", line 46, in 
from lmgr.layertreeimport LayerTree, LMIcons
  File "/usr/lib/grass64/etc/wxpython/lmgr/layertree.py", line 37, in

from mapdisp.frame   import MapFrame
  File "/usr/lib/grass64/etc/wxpython/mapdisp/frame.py", line 52, in

from wxplot.profile import ProfileFrame
  File "/usr/lib/grass64/etc/wxpython/wxplot/profile.py", line 23, in

import wx.lib.plot as plot
  File
"/usr/lib64/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/lib/plot.py",
line 523, in 
class PlotCanvas(wx.Panel):
  File
"/usr/lib64/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/lib/plot.py",
line 1817, in PlotCanvas
_multiples = [(2., _Numeric.log10(2.)), (5., _Numeric.log10(5.))]
AttributeError: 'module' object has no attribute 'log10'


   Obviously, this is an issue with only the wxpython interface (cli still
works, as does old tcltk interface), and although the error stems from
wxNVIZ, I think it is due to GRASS being confused about where to find
NumPy... I've tried to "clean up" my python installs, including
reinstalling  both python 2.6 and 2.7, NumPy, SciPy, and wxWidgets (both
2.6 and 2.7). I've also reinstalled GRASS (and tried the older version of
6.4 in the standard Ubuntu repository), but this error still stands. Any
ideas about what I can do to fix it?

Many thanks for any help offered!
-- 
Isaac I Ullah, Ph.D.

***
isaac.ul...@asu.edu
ul...@archaeologist.com

http://www.public.asu.edu/~iullah
***
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.clump4p - OpenMP version of r.clump

[Moritz Lennert]

On 23/02/14 23:10, Markus Metz wrote:

There is an OpenMP version of r.clump available at

http://sil.uc.edu/downloads.html#software

called r.clump4p. The reported performance gain is 450 times over the
original r.clump.

The performance gain over the original r.clump vanished:
r.clump4p with one thread is now about 12x slower than r.clump, and
r.clump4p with 4 threads is now about 5x slower than r.clump.
Moreover, the results of r.clump4p are wrong, it clumps together areas
with different cell values (no multithreading effect).

I tested in a region with 650 million cells, both modules produced
about 17.6 million clumps. All differences in the resultant clumps
were due to errors in r.clump4p.

Tests were performed in GRASS 7 where I have optimized r.clump and
also added support for diagonal clump tracing.


Great work ! Thanks a lot, Markus !

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