Re: [GRASS-dev] port of v.points.cog to python
On Sat, Mar 07, 2015 at 11:16:21AM +0100, Moritz Lennert wrote: Am 07.03.2015 10:43 schrieb Markus Metz: On Sun, Mar 1, 2015 at 5:01 PM, Patrice Dumas pertu...@free.fr wrote: Hello, Here is a rewrite of the v.points.cog module in python. I think v.points.cog is superseded by v.centerpoint which offers cog as well as other kinds of centerpoints. AFAIR, v.points.cog offers the possibility to get cog for clusters of points defined by an attribute. v.centerpoint does not offer this. So, either it might be interesting to add this to v.centerpoint, or to rewrite v.points.cog as a wrapper around v.centerpoint. I think that using v.centerpoint in v.points.cog would be the best, as it would then be possible to add a pcenter= option to v.points.cog to be able to use v.centerpoint other possibilities. I can do that, but I think that it is best to first commit the translation of v.points.cog as is and in a second step add the call to v.centerpoints instead of duplicating in v.points.cog what v.centerpoints does. Is it ok? -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] port of v.points.cog to python
Hello, Here is a rewrite of the v.points.cog module in python. I tried translating code only, keeping the code organization, variables names as it was previously to help those who would want to review the differences with the shell script. I also did the few changes required for changes in grass7, but there weren't that much since python function already abstract some commands. I did a svn copy of the grass6 module before doing the modifications. I cannot (and don't want to...) claim any copyright on a code translation. I didn't test thoroughly, but since it is code translation, I don't expect big surprises. -- Pat Index: grass7/vector/Makefile === --- grass7/vector/Makefile (révision 64773) +++ grass7/vector/Makefile (copie de travail) @@ -35,6 +35,7 @@ v.out.ply \ v.out.png \ v.ply.rectify \ + v.points.cog \ v.stats \ v.surf.icw \ v.surf.mass \ Index: grass7/vector/v.points.cog/description.html === --- grass7/vector/v.points.cog/description.html (révision 64773) +++ grass7/vector/v.points.cog/description.html (copie de travail) @@ -1,53 +0,0 @@ -h2DESCRIPTION/h2 - - -emv.points.cog/em condenses points or centroids sharing -a common attribute into a single point in a new vector map at their -average position (center of gravity). -p -For this to work well your clusters of points must be gregarious -(Gaussian distribution) - if two groups of points habitate in two -corners of the map the output point will fall in the center and -match niether well. -p -If needed you can use emv.digit/em to adjust point positions -created by this module, !-- repel 2 points if v.distance minimum? -- -or use this module as a preprocessing step before running -emv.label.sa/em to deal with overlapping labels automatically. - -!--p appropriate for lat/lon? (weighted avg for y by cos(y)?) -- - - -h2EXAMPLE/h2 - -Create single points at the average of all points in the -ttbugsites/tt map, and place a single label there. - -div class=codepre -v.points.cog in=bugsites out=bug_cog column=str1 - -d.vect -c bugsites color=none icon=basic/circle - -d.vect bug_cog disp=attr attrcol=str1 lcolor=black \ - lsize=14 xref=center yref=center bgcolor=white -/pre/div - - -h2SEE ALSO/h2 -em -a href=v.label.sa.htmlv.label.sa/abr -a href=v.label.htmlv.label/abr -a href=v.digit.htmlv.digit/a -/em - - -h2AUTHOR/h2 - -Hamish Bowmanbr -iDept. Marine Sciencebr -University of Otagobr -Dunedin, New Zealand/i -br - -p -iLast changed: $Date$/i Index: grass7/vector/v.points.cog/v.points.cog === --- grass7/vector/v.points.cog/v.points.cog (révision 64773) +++ grass7/vector/v.points.cog/v.points.cog (copie de travail) @@ -1,142 +0,0 @@ -#!/bin/sh -# - -# -# MODULE: v.points.cog -# -# AUTHOR(S):Hamish Bowman -# -# PURPOSE: Condense points or centroids sharing a common attribute into a single point -# -# COPYRIGHT:(c) 2010 Hamish Bowman, and the GRASS Development Team -# -# This program is free software under the GNU General Public -# License (=v2). Read the file COPYING that comes with GRASS -# for details. -# -# -#%Module -#% description: Condense points or centroids sharing a common attribute into a single point. -#% keywords: vector, cluster -#%End -#%option -#% key: input -#% type: string -#% gisprompt: old,vector,vector -#% description: Name of input vector map -#% required : yes -#%end -#%option -#% key: output -#% type: string -#% gisprompt: new,vector,vector -#% description: Name for output vector map -#% required : yes -#%end -#%option -#% key: column -#% type: string -#% description: Column containing common attribute -#% required : yes -#%end -#%option -#% key: layer -#% type: integer -#% answer: 1 -#% description: Layer number -#% required: no -#%end - -##%option -##% key: type -##% type: string -##% description: Feature type(s) -##% options: point,centroid -##% answer: point -##% required: no -##% multiple: yes -##%end - - -if [ -z $GISBASE ] ; then -echo You must be in GRASS GIS to run this program. 12 -exit 1 -fi - -if [ $1 != @ARGS_PARSED@ ] ; then -exec g.parser $0 $@ -fi - -MAP=$GIS_OPT_INPUT -COLUMN=$GIS_OPT_COLUMN -LAYER=$GIS_OPT_LAYER - -# check for input map -eval `g.findfile element=vector file=$MAP` -if [ ! $file ] ; then -g.message -e Vector map $MAP does not exist. -exit 1 -fi - -# check for column -if [ `v.info -c $MAP layer=$LAYER --quiet | cut -f2 -d'|' | grep -c ^$COLUMN$` -ne 1 ] ; then -g.message -e Column $COLUMN not found. -exit 1 -fi - -# get column details so we can recreate it. -# The db.* modules need special
Re: [GRASS-dev] [GRASS-user] minimal wxPython version
On Tue, Mar 19, 2013 at 02:39:33PM +0100, Anna Kratochvílová wrote: Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? epel 5 (add-on repository for rhel 5, the oldest still maintained rhel distribution) has 2.8.12. I am not sure that more conservative repositories have this version, but at least it is available in one repository with a sufficiently high version. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Integrate XDR lib into GRASS?
On Wed, Mar 21, 2012 at 02:42:27PM +0100, Markus Neteler wrote: Hi, here at the FOSSGIS.de conference we tried to compile GRASS for Android. A major obstacle was XDR (e.g., https://svn.r-project.org/R/trunk/src/extra/xdr). Since it is only 4 files (or perhaps less used), why not incorporating these files into the GRASS source code? Maybe it would be overkill, but gnulib is designed for such portability issues, maybe grass could use that more generally? http://www.gnu.org/software/gnulib/ I checked that there is some xdr support (from glibc): http://www.gnu.org/software/gnulib/manual/html_node/Glibc-rpc_002fxdr_002eh.html#Glibc-rpc_002fxdr_002eh There is an entry cost, though, and it integrates better when automake is used too. Also the fact that grass requires an old autoconf may be troublesome. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Integrate XDR lib into GRASS?
On Wed, Mar 21, 2012 at 04:24:11PM +0100, Markus Neteler wrote: On Wed, Mar 21, 2012 at 3:18 PM, Patrice Dumas pertu...@free.fr wrote: On Wed, Mar 21, 2012 at 02:42:27PM +0100, Markus Neteler wrote: ... Since it is only 4 files (or perhaps less used), why not incorporating these files into the GRASS source code? Maybe it would be overkill, but gnulib is designed for such portability issues, maybe grass could use that more generally? http://www.gnu.org/software/gnulib/ I checked that there is some xdr support (from glibc): http://www.gnu.org/software/gnulib/manual/html_node/Glibc-rpc_002fxdr_002eh.html#Glibc-rpc_002fxdr_002eh There is an entry cost, though, and it integrates better when automake is used too. Also the fact that grass requires an old autoconf may be troublesome. Unfortunately it will not help: http://www.gnu.org/software/gnulib/manual/html_node/xdrmem_005fcreate.html#xdrmem_005fcreate - Portability problems not fixed by Gnulib: This function is missing on some platforms: Cygwin 1.7.4, mingw, BeOS. ... and MingW is one of the relevant platforms... Indeed, it seems in fact that none of xdr* are really implemented, so that the platforms where the function is missing are merely listed... But if R and grass both need it, that's a hint that it may make sense to add them, even though you don't end up using it! I'll certainly go ask on the gnulib mailing list whether there is specific issue with xdr and gauge the interest there. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] in trunk png/cairo d.vect overwrites previous images?
On Tue, Jan 31, 2012 at 10:36:01AM +0100, Moritz Lennert wrote: This behaviour is controlled by the GRASS_PNG_READ environment variable. If you set it to TRUE, then GRASS will lay the new d.vect on top of the already drawn vectors, otherwise it overwrites with the new. See http://grass.osgeo.org/grass70/manuals/html70_user/cairodriver.html. Thanks. I was pretty sure I missed something although I did read the Fine Manual before asking... Maybe the GRASS_PNG_READ description could be enhanced by adding Otherwise the GRASS_PNGFILE file content is overwritten each time a new display command is used. Also I think that the Example should also set export GRASS_PNG_READ=TRUE otherwise it doesn't really make sense as the elevation raster will not appear on map.png. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] in trunk png/cairo d.vect overwrites previous images?
On Tue, Jan 31, 2012 at 11:15:47AM +0100, Moritz Lennert wrote: otherwise it doesn't really make sense as the elevation raster will not appear on map.png. Here's what I see as example on the page: export GRASS_RENDER_IMMEDIATE=cairo export GRASS_PNGFILE=nc_spm.png export GRASS_WIDTH=800 export GRASS_HEIGHT=800 export GRASS_PNG_READ=TRUE g.region rast=elevation d.rast map=elevation d.vect map=streams width=1 color=blue fcolor=aqua type=area,line d.vect map=roadsmajor width=2 i.e. GRASS_PNG_READ is set... :-) Ah, ok, I was looking at http://grass.osgeo.org/grass70/manuals/html70_user/pngdriver.html There it is not set. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] patch for grass_trunk d.vect.thematic
On Tue, Jan 31, 2012 at 11:36:51AM +0100, Moritz Lennert wrote: On 31/01/12 11:24, Moritz Lennert wrote: On 30/01/12 23:10, Patrice Dumas wrote: Hello, A little patch for d.vect.thematic.py in trunk. It shows up if you use d.vect.thematic themetype=graduated_points It fixes 2 things. An unquoted string graduated_lines. f_psmap not being initialized although it is used line 1049. I moved the f_psmap initialization before. Thanks, I'll apply it in SVN. Done. Thanks ! -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] patch for grass_trunk d.vect.thematic
Hello, A little patch for d.vect.thematic.py in trunk. It shows up if you use d.vect.thematic themetype=graduated_points It fixes 2 things. An unquoted string graduated_lines. f_psmap not being initialized although it is used line 1049. I moved the f_psmap initialization before. -- Pat Index: scripts/d.vect.thematic/d.vect.thematic.py === --- scripts/d.vect.thematic/d.vect.thematic.py (révision 50573) +++ scripts/d.vect.thematic/d.vect.thematic.py (copie de travail) @@ -427,6 +427,7 @@ } # graduated color thematic mapping +f_psmap = file(tmp_psmap, 'w') if themetype == graduated_colors: if colorscheme in colorschemes: startc, endc = colorschemes[colorscheme] @@ -728,7 +729,6 @@ where = sqlwhere, color = linecolor, fcolor = themecolor, icon = icon, size = ptsize) -f_psmap = file(tmp_psmap, 'w') if type in [line, boundary]: out(f_psmap, locals(), \ vlines $map @@ -914,7 +914,7 @@ lineht = 4 if i xlower or i = xupper: -if themetype == graduated_lines: +if themetype == graduated_lines: out(f_graph, locals(), \ color $linecolor ) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] in trunk png/cairo d.vect overwrites previous images?
Hello, I ask here first before because this seems a bit weird that nobody else reported it, but maybe I missed a bug report or something changed in grass 7? When doing more than one d.vect after a d.mon start=png (or cairo) the last one overwrite completly the previous one. With wx0 or 6.4 the vector was on top but did not remove the previous vector. Should I report that or is it known? -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] projection of vectors accros wrapping map boundaries
On Thu, Dec 29, 2011 at 05:52:16PM +0100, Markus Neteler wrote: Yes, for both 6.4 and 7 cases would be ideal. That increases tremendously the motivation to try and fix it :) For 7, I have filled http://trac.osgeo.org/grass/ticket/1527 For 6.4, I don't remember exactly the issue, and I don't have a simple reproducer, nor a test platform, so I am not able to report it for now. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] projection of vectors accros wrapping map boundaries
Hello, With yesterday svn trunk version. I have come accross something that I think is a bug, but before opening a ticket, I'd have preferred to have a confirmation that it is indeed a bug and not a feature, and also I tried to find a mention of this issue on the web, but couldn't find one which surprises me a bit. When I project a vector from a location thet overlaps with a wrapping boundary of a map, the vector is split in two. For example, I have a longitude latitude location covering the whole world, that wraps somewhere in the Pacific (that is points on the eastern boundary are also on the western boundary). When I project a vector constructed by doing a grid on a Lambert equal area location centered somewhere in the Pacific, the grid cells (that are, in that case, no more rectangular) that fall on the boundary are cut in two, with warnings like: WARNING: Number of centroids exceeds number of areas: 900 847 WARNING: Number of incorrect boundaries: 507 WARNING: Number of centroids outside area: 53 My first guess is that it is related with the recent change in topography of the vectors (not that I understand what is going on...). grass 6.4 behaves much better (although I also remember seeing an issue with wrapping of vectors, this looked like a subtle issue). Should I open a ticket with a reproducer? Note: I have had these kind of error messages in another case with grass 7, although there were no error messages with grass 6.4, but I think that in this case, the error messages were legitimate, and the output was as correct as it could be. This happened when I projected vectors (corresponding to countries) from a world longitude latitude location to a smaller location (on a Lambert equal area projection), and the vectors were not completly contained in the smaller location, or even had their centroid outside of the smaller location they were projected in. -- Pat ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
