Re: [GRASS-dev] v.kcv enahncement- was Re: How to calculate mean coordinates from big point datasets?

[Markus Metz]

Helena Mitasova wrote:
> Markus,
>
> when you are at it, can you also have a look at v.kcv?
> http://grass.osgeo.org/grass70/manuals/v.kcv.html
>
> I am wondering whether it works efficiently with lidar data sets (millions of 
> points) - I heard that it takes forever,
> but that was about a year ago and I haven't tried it myself.

v.kcv has been improved recently in trunk, thanks to Jan Vandrol and
Jan Ruzicka.

> For example, if I want to partition the data set into 1% test points and 99% 
> given data points (for example to test
> interpolation) it appears I may need 100 partitions as there is no way to 
> have just two partitions with different size.

The number of partitions does not influence speed (in trunk).
>
> One of the problems may be the table - perhaps if this was run without the 
> table and the output was written into
> two (or k) separate files, it could be faster?

Yes, updating the table can be slow. For a large number of points it
is recommended to not use dbf. Creating a separate new vector for each
partition could be an alternative.

> The core of the algorithm which is based on finding the closest
> points to the set of random points should allow this.

This is the part that makes v.kcv slow in 6.x.

> Creating a subset of points which are farther apart than given threshold (2d 
> or 3d distance) would be also useful
> (it is done internally in v.surf.rst and I have a version which does it with 
> 3D distances, but the resulting subset is not
> written into output file).

For that you would need a spatial search structure in order to be
reasonably fast. I guess that v.surf.rst uses quad- or oct-trees for
this purpose.

>
> This is not urgent but if it is not too difficult  it would be nice to have,
> or let us know if it already works and I just cannot find the right module,

As of 2013-07-19, v.kcv in trunk is much faster than in 6.x. Creating
subsets of points which are farther apart than given threshold is not
implemented, but that would not be too difficult to add using a
spatial index for each partition.

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

Re: [GRASS-dev] Script directory in build GRASS session

[Michael Barton]

I do get the errors that Helena shows, but they don't seem to affect the 
compilation--at least not obviously. BUT, it is possible that whatever is 
causing these is also causing my compilation to fail. 

What it acts like is that it is somehow hard coded to look for Python 2.7, but 
I'm compiling with 2.6. Glynn thinks it may be somewhere in some CTypes code.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu












On Sep 22, 2013, at 8:41 PM, Helena Mitasova  wrote:

> 
> On Sep 22, 2013, at 11:04 PM, Vaclav Petras wrote:
> 
>> I added the script directory into PATH for build session, see r57814.
>> 
>> This makes sense (bin is there too) and moreover it should fix missing 
>> descriptions and keywords for modules in wxGUI menu and module tree. Note 
>> that you wouldn't saw this problem if gui/wxpython is compiled in (standard) 
>> GRASS session. Maybe this change will fix menudata.xml problem for Micheal's 
>> compilation, but I'm afraid that it will not.
> 
> I just updated grass7 and the problem is still there for MacOSX10.6.
> I assume that Michael refers to these
> 
>> Errors in:
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/animation
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/mapswipe
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/gmodeler
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/rlisetup
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/psmap
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/dbmgr
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/vdigit
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/iclass
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/gcp
>> /Users/helena/grassdev7/grass_trunk/gui/wxpython/timeline
> 
> Helena
>> 
>> Vaclav
>> 
>> https://trac.osgeo.org/grass/changeset/57814
>> ___
>> 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] Script directory in build GRASS session

[Helena Mitasova]

On Sep 22, 2013, at 11:04 PM, Vaclav Petras wrote:

> I added the script directory into PATH for build session, see r57814.
> 
> This makes sense (bin is there too) and moreover it should fix missing 
> descriptions and keywords for modules in wxGUI menu and module tree. Note 
> that you wouldn't saw this problem if gui/wxpython is compiled in (standard) 
> GRASS session. Maybe this change will fix menudata.xml problem for Micheal's 
> compilation, but I'm afraid that it will not.

I just updated grass7 and the problem is still there for MacOSX10.6.
I assume that Michael refers to these

> Errors in:
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/animation
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/mapswipe
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/gmodeler
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/rlisetup
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/psmap
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/dbmgr
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/vdigit
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/iclass
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/gcp
> /Users/helena/grassdev7/grass_trunk/gui/wxpython/timeline

Helena
> 
> Vaclav
> 
> https://trac.osgeo.org/grass/changeset/57814
> ___
> 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] Script directory in build GRASS session

[Vaclav Petras]

I added the script directory into PATH for build session, see r57814.

This makes sense (bin is there too) and moreover it should fix missing
descriptions and keywords for modules in wxGUI menu and module tree. Note
that you wouldn't saw this problem if gui/wxpython is compiled in
(standard) GRASS session. Maybe this change will fix menudata.xml problem
for Micheal's compilation, but I'm afraid that it will not.

Vaclav

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

Re: [GRASS-dev] How to access the value of each cell for every row column with pygrass?

[Hamish]

Nick wrote:

> Using pygrass is it possible to create a matrix or a numpy
> array which will contain each cell's  value?
>
> Something similar like gdals ReadAsArray function?


have a look at the RasterNumpy class,

https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/docs/raster.rst#L308



Hamish

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

[GRASS-dev] v.kcv enahncement- was Re: How to calculate mean coordinates from big point datasets?

[Helena Mitasova]

Markus,

when you are at it, can you also have a look at v.kcv?
http://grass.osgeo.org/grass70/manuals/v.kcv.html

I am wondering whether it works efficiently with lidar data sets (millions of 
points) - I heard that it takes forever,
but that was about a year ago and I haven't tried it myself.
For example, if I want to partition the data set into 1% test points and 99% 
given data points (for example to test
interpolation) it appears I may need 100 partitions as there is no way to have 
just two partitions with different size. 

One of the problems may be the table - perhaps if this was run without the 
table and the output was written into 
two (or k) separate files, it could be faster? The core of the algorithm which 
is based on finding the closest 
points to the set of random points should allow this.
Creating a subset of points which are farther apart than given threshold (2d or 
3d distance) would be also useful
(it is done internally in v.surf.rst and I have a version which does it with 3D 
distances, but the resulting subset is not
written into output file).

This is not urgent but if it is not too difficult  it would be nice to have,
or let us know if it already works and I just cannot find the right module,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may 
be disclosed to third parties.” 

On Sep 22, 2013, at 11:06 AM, Markus Metz wrote:

> Markus Neteler wrote:
>> Hi,
>> 
>> I came across this question:
>> 
>> http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets
> 
> Please try the new addon v.centerpoint [0]. It calculates various
> center points for point clouds, lines, and areas. Standard options are
> the geometric mean (center of gravity) and geometric median (more
> robust for outliers). There are additional options to calculate center
> points for points, lines and areas, explained in the manual. The
> geometric medians (points of minimum distance to all other points) are
> approximations, but fairly accurate and very fast. I would be
> surprised if any other GIS software can calculate these center points.
> 
> Markus M
> 
> [0] http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/vector#v.centerpoint
> ___
> 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] How to access the value of each cell for every row column with pygrass?

[Nick Ves]

Hey List,

Using pygrass is it possible to create a matrix or a numpy array which will
contain each cell's  value?

Something similar like gdals ReadAsArray function?

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

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

[Markus Metz]

Markus Neteler wrote:
> Hi,
>
> I came across this question:
>
> http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets

Please try the new addon v.centerpoint [0]. It calculates various
center points for point clouds, lines, and areas. Standard options are
the geometric mean (center of gravity) and geometric median (more
robust for outliers). There are additional options to calculate center
points for points, lines and areas, explained in the manual. The
geometric medians (points of minimum distance to all other points) are
approximations, but fairly accurate and very fast. I would be
surprised if any other GIS software can calculate these center points.

Markus M

[0] http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/vector#v.centerpoint
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles

[GRASS GIS]

#2077: implement drop-down menu for barscale styles
--+-
  Reporter:  martinl  |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  reopened 
  Priority:  major|   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-trunk
Resolution:   |Keywords:  d.barscale   
  Platform:  All  | Cpu:  All  
--+-

Comment(by hamish):

 Replying to [comment:16 wenzeslaus]:
 > Do we know that documentation is always in `$GISBASE/docs/html` on all
 platforms?
 > Are there any distributions which put the documentation somewhere else?

 fwiw Debian has it's strict packaging rules, so the html dir is installed
 to /usr/share/doc/grass-doc/html/ and $GISBASE/docs/html is a symlink to
 that, so GRASS doesn't have to do anything special. (& GRASS man pages are
 installed to /usr/share/man/man1/)


 regards,
 Hamish

-- 
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] #2077: implement drop-down menu for barscale styles

[GRASS GIS]

#2077: implement drop-down menu for barscale styles
--+-
  Reporter:  martinl  |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  reopened 
  Priority:  major|   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-trunk
Resolution:   |Keywords:  d.barscale   
  Platform:  All  | Cpu:  All  
--+-

Comment(by hamish):

 Replying to [comment:18 martinl]:
 > Similarly we could include symbols thumbnails in d.vect's manual
 > page and probably move `gui/images/symbols` to `display/d.vect/symbols`
 (?)

 not for symbols because symbols are independent of d.vect (e.g. d.graph,
 ps.map), whereas d.barscale contains the code to render the barscale
 internally.

 for the color scales r.colors makes them as part of its Makefile, so it
 makes some sense for them to be built into raster/r.colors/ then installed
 from there.

 Don't worry about prepping things for the debian/ubuntu packaging, it's
 all manually picked into the various packages by hand & 'make install' is
 not run there. A goal of the packaging is to keep platform dependent code
 (e.g. exe binaries) and platform independent code (e.g. help pages, png
 images) in separate packages so the platform-independent files can be
 shared across all, and only the platform-specific files need to be
 duplicated on the download servers. (etc/ is a bit of a tricky one to
 untangle, since it has both in the same dir structure and while hand
 picked, it's easier to do/maintain that by dir than by file)

 Having said that, I don't think it's a big deal if the help pages have
 broken links to the thumbnails if the grass-gui package is not installed,
 it's more important that the drop-down menus work. Duplication is not
 good, but I can see the case where the docs should be self-contained in
 html/ dir (+subdirs). Similarly, I can see the case that the GUI shouldn't
 have to hunt in $GISBASE/etc/docs/ for support files, but I guess anything
 in etc/ is fair game. These files are pretty tiny anyway..


 > AFAIK, sed is required.

 note that 'sed' is ok, but 'sed -i' is not portable to Mac/BSD.


 thanks,
 Hamish

-- 
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] #2077: implement drop-down menu for barscale styles

[GRASS GIS]

#2077: implement drop-down menu for barscale styles
--+-
  Reporter:  martinl  |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  reopened 
  Priority:  major|   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-trunk
Resolution:   |Keywords:  d.barscale   
  Platform:  All  | Cpu:  All  
--+-

Comment(by martinl):

 Replying to [comment:17 martinl]:
 > Replying to [comment:16 wenzeslaus]:
 > > The GUI should depend on documentation not the other way around, so 2
 or 1 are the right options.
 >
 > Agreed, I would suggest to move barscale thumbs to `display/d.barscale`
 and copy them to `$GISBASE/docs/html` (similarly to `r.colors`'s color
 tables).

 done in r57801. Similarly we could include symbols thumbnails in d.vect's
 manual page and probably move `gui/images/symbols` to
 `display/d.vect/symbols` (?)

-- 
Ticket URL: 
GRASS GIS 

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