[GRASS-dev] Re: [GRASS GIS] #422: broken (d.)barscale
#422: broken (d.)barscale --+- Reporter: martinl | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: major| Milestone: 7.0.0 Component: Display | Version: svn-trunk Resolution: fixed|Keywords: cairo Platform: Unspecified | Cpu: Unspecified --+- Changes (by neteler): * status: new = closed * resolution: = fixed Comment: Thanks, fixed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/422#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #424: AC_CONFIG_AUX_DIR added in configure.in of 6.4.x causes rpmbuild failure
#424: AC_CONFIG_AUX_DIR added in configure.in of 6.4.x causes rpmbuild failure --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: 6.4.0 RCs Resolution: wontfix |Keywords: Platform: Linux| Cpu: All --+- Changes (by neteler): * status: new = closed * resolution: = wontfix Comment: Replying to [comment:2 glynn]: Replying to [ticket:424 neteler]: libtoolize: cannot handle variables in AC_CONFIG_AUX_DIR ... It's needed, and I don't think that it can be conditionalised. OK, changing in the SPEC file %configure to ./configure works around the problem since libtool(ize) is then not used. -- Ticket URL: http://trac.osgeo.org/grass/ticket/424#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: grass-user Digest, Vol 33, Issue 10
On 06/01/09 22:18, Michael Barton wrote: From: Benjamin Ducke benjamin.du...@oxfordarch.co.uk Subject: Re: [GRASS-user] v.centroids and cat values Cc: grass-user grass-u...@lists.osgeo.org Message-ID: 1559037892.138311231273729471.javamail.r...@mail.thehumanjourney.net Content-Type: text/plain; charset=utf-8 GRASS modules that create area type features should already be generating centroids and adding categories to them automatically, shouldn't they? I don't know. As far as I am aware, e.g., v.in.ogr does this, so we are talking mainly about adding centroid generation to the interactive digitizing tool, aren't we? In this case yes. I don't know about other modules. The GRASS Vector lib API should have a function that finds a good centroid automatically. Or am I misled here (guess I am getting a bit confused myself, now)? This is a good idea. If it exists, perhaps it should be accessed by the digitizing module as the default. To be quite honest, I have always been a bit bewildered about the choice of using a centroid point for linking attributes to area features. Could anyone here fill me in on what advantage that has? In a topological model where a boundary is boundary of two adjacent polygons, you cannot link polygon attributes to the boundary as there would be ambiguity as to which polygon these attributes are referring to. So you need some way of unambiguously identifying the polygon. A pseudo-centroid (i.e. not the geometric centroid, but one that in all cases lies within the polygon) is one way of doing it and the one chosen in GRASS's vector model. There might be other ways, but I'm no expert on that. My bet is that is is a legacy of early GRASS vector design--a convenient way to create a polygon and give it some data. I still find it strange that a boundary can exist that is not a line and not a part of an area. On Jan 6, 2009, at 11:06 AM, Patton, Eric wrote: If the user just wants to digitize a boundary without areas, then they could just digitize linework and snap the vertices, couldn't they? You might have a case where you need information concerning areas, but also information concerning their boundaries, i.e. just as an example off the top of my head, you could have migration balances for countries (polygons) and information concerning the permeability of the borders (boundaries). You could obviously use a separate layer of lines to represent your borders and link the attributes to that, but the GRASS model allows you to have both in the same map, with centroids in one layer linked to their attributes, and the borders in a second layer linked to theirs. I have no idea how frequent such usage is, though... Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #419: cairo compilation error
#419: cairo compilation error --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: default | Version: svn-trunk Resolution: |Keywords: Platform: Linux| Cpu: x86-32 --+- Comment (by mlennert): Replying to [comment:1 glynn]: Replying to [ticket:419 neteler]: Trying to compile GRASS trunk on grass.osgeo.org (FC4 with cairo 1.4.4), I get Draw_bitmap.c:36: error: implicit declaration of function 'cairo_format_stride_for_width' What's the minimum version of cairo needed here? That function needs 1.6. Looks like 1.5.8 would be enough: http://cairographics.org/news/cairo-1.5.8/ I have the same problem with cairo_xlib_surface_get_xrender_format Moritz Please update REQUIREMENTS.html: I'd rather work around the requirement. -- Ticket URL: http://trac.osgeo.org/grass/ticket/419#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #398: r.watershed with MFD
#398: r.watershed with MFD --+- Reporter: mmetz| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: reopened Priority: minor| Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): A new patch against trunk r35238 is attached, named r.watershed.20090107.patch This patch includes the following changes: - MFD flow accumulation is slightly improved. - MFD streams and basins are now equal to or better than SFD streams and basins (they look more natural, no slivers or rectangles). Striking differences are visible with elev_lid792_1m (multiplied by 1000 to get mm accuracy) in nc_spm_08. - Segmented mode is slightly faster, more noticeable with larger regions. - In segmented mode, the dseg routines for DCELL output maps were actually writing out CELL maps, not DCELL maps, changed to DCELL maps. DCELL_TYPE is required for LS and S factor for USLE and for flow accumulation. - Improved color rules for flow accumulation based on standard deviation and log transformation, visual output would be obsolete now. BTW, in visual output all cells with negative flow accumulation (offmap inflow) are set to zero. That's an old, existing feature. - In segmented mode, G_percent() in length slope determination is now counting up, no longer counting down (was a FIXME). Can you developers please test this patch? Thanks! Happy New Year, Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/398#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #419: cairo compilation error
#419: cairo compilation error --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: default | Version: svn-trunk Resolution: |Keywords: Platform: Linux| Cpu: x86-32 --+- Comment (by glynn): Replying to [comment:3 mlennert]: What's the minimum version of cairo needed here? Looks like 1.5.8 would be enough: I'll update the test accordingly. I have the same problem with cairo_xlib_surface_get_xrender_format That should be conditionalised upon CAIRO_HAS_XLIB_XRENDER_SURFACE. The function should be defined in cairo-xlib-xrender.h. Can you provide more details? -- Ticket URL: http://trac.osgeo.org/grass/ticket/419#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: wingrass640
Hi all, is there someone (Marco?) who is going to prepare Windows installer for RC1 with wxGUI support (propably except of vector digitizer and Nviz extension)? I'm just back in office. I'm 455 mails late... but I'll start to work on the new GRASS build right now. The blocking thing is related to the building environment update I planned; in fact, some problems in the GRASS building are generated by some MSYS/MinGW lacks... that's why I decided to replace my current MSYS installation with a fully updated one... and here that's the problem! the MSYS project is poorely documented, and the 1.0.11 version of the istaller, even if available on the repository, is not officially present in the project list... but it seems to be more recent (and bug fixer) than the currently proposed one... even if not fully updated! and the updated are a little be confused (in the way you cannot just unpack the new files because some updates overwrite each other creating messy and buggy installations). I've been reading some articles and mails and I'm figuring how to solve this messy situation... I think I can give you a precise dead-line in about one or two days. I'm sorry, but I also have my regular work here ;) ... I'll do as best as I can. Regards... and happy new year :) - Ing. Marco Pasetti Università degli Studi di Brescia Facoltà di Ingegneria Dipartimento di Ingegneria Meccanica e Industriale Via Branze, 38 - 25123 Brescia - Italy Phone: (+39) 030 371 54 97 Mobile: (+39) 328 56 12 639 Skype: marco.pst - ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compile error in grass-6.4.0RC1/gui/wxpython
Dear developers, On Mon, 29 Dec 2008 16:07:30 +0100 Otto Dassau otto.das...@gmx.de wrote: Dear developers, I wanted to build GRASS 6.4.0 RC1 packages under OpenSuSE 11.0 and got errors in grass-6.4.0RC1/gui/wxpython. I changed into the directory and tried with 'make' again. I attached the error messages, maybe someone can have a look and help? after reading and following the README in http://svn.osgeo.org/grass/grass/branches/develbranch_6/gui/wxpython/ I still get some error messages: make[3]: Entering directory `/usr/src/packages/BUILD/grass-6.4.0RC1/gui/wxpython' python gui_modules/menudata.py /usr/src/packages/BUILD/grass-6.4.0RC1/dist.i686-pc-linux-gnu menustrings.py Traceback (most recent call last): File gui_modules/menudata.py, line 24, in module import elementtree.ElementTree as etree # Python = 2.4 ImportError: No module named elementtree.ElementTree make[3]: *** [menustrings.py] Error 1 make[3]: Leaving directory `/usr/src/packages/BUILD/grass-6.4.0RC1/gui/wxpython' make[2]: *** [install_scripts] Error 2 make[2]: Leaving directory `/usr/src/packages/BUILD/grass-6.4.0RC1/gui/wxpython' make[1]: Leaving directory `/usr/src/packages/BUILD/grass-6.4.0RC1/gui' make[1]: Entering directory `/usr/src/packages/BUILD/grass-6.4.0RC1/imagery' Maybe someone has an idea what to do here? Is there something else (a python module) missing? thanks a lot Otto thanks a lot Otto ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compile error in grass-6.4.0RC1/gui/wxpython
Hi, 2009/1/7 Otto Dassau otto.das...@gmx.de: [...] make[3]: Entering directory `/usr/src/packages/BUILD/grass-6.4.0RC1/gui/wxpython' python gui_modules/menudata.py /usr/src/packages/BUILD/grass-6.4.0RC1/dist.i686-pc-linux-gnu menustrings.py Traceback (most recent call last): File gui_modules/menudata.py, line 24, in module import elementtree.ElementTree as etree # Python = 2.4 ImportError: No module named elementtree.ElementTree in Debian it's python-elementtree. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: r.walk, r.cost r.drain patches posted
Thanks for the updates. I'll give them a try. While I understand the reason for the gaps in the paths now, I think that it is important to find some way to get rid of them. That is, there needs to be some algorithm that will 'connect the dots' of knights move jumps. I certainly agree but it should be done without adding cells in between. The knight's moves should be retained in the output. We need some kind of vectorization algorithm which connects cell center to cell center, or which joins all the little line segments that would be produced by a discontinuous path. Even without vectorizing, the cell accumulation values will be inaccurate if cells are skipped in a path from point A to point B. The algorithm accounts for the accumulation value in these larger jumps using pythagoras. Just as diagonals are multiplied by ~1.4, knight's move jumps are multiplied by ~2.2 (but depending on the resolution, etc.). -Colin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #422: broken (d.)barscale
#422: broken (d.)barscale
--+-
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major| Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: |Keywords: cairo
Platform: Unspecified | Cpu: Unspecified
--+-
Changes (by martinl):
* status: closed = reopened
* resolution: fixed =
Comment:
Not really, try
{{{
d.barscale -s
}}}
Screenshot attached.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/422#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New addon in svn: v.db.calc
I just added the new script for field calculation. It basically applies a python expression allowing the usage of field names as variables and update the selected column values. It is useful for advanced field updates with DBF files. An example: Add a new column named EXP and populate it with the values of column VAL elevated at 0.25: v.db.addcol map=myvector columns=EXP double v.db.calc input=myvector field=EXP exp=math.pow([VAL], 0.25) if the field is text: Add a new text column named TXT and populte it concatenating em Dr. /em and the text values of the column NAME where the TITLE is phd: v.db.addcol map=owners columns=TXT varchar(25) v.db.calc input=owners field=TXT exp='Dr. '+'[NAME]' where=TITLE=phd It should virtually works with all the python libs, but I've just tested with math and common functions. Please test and comment. Maxi -- - Dr. Massimiliano Cannata Environmental Geomatic Engineer Institute of Earth Sciences - SUPSI Trevano, C.P. 72, CH-6952 Canobbio, SWITZERLAND Tel:+41 (0)58 / 666 62 14 Fax:+41 (0)58 / 666 62 09 E-mail: massimiliano.cann...@supsi.ch Web: http://www.ist.supsi.ch http://istgis.ist.supsi.ch:8001/geomatica/ --- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compile error in grass-6.4.0RC1/gui/wxpython
Martin Landa wrote: make[3]: Entering directory `/usr/src/packages/BUILD/grass-6.4.0RC1/gui/wxpython' python gui_modules/menudata.py /usr/src/packages/BUILD/grass-6.4.0RC1/dist.i686-pc-linux-gnu menustrings.py Traceback (most recent call last): File gui_modules/menudata.py, line 24, in module import elementtree.ElementTree as etree # Python = 2.4 ImportError: No module named elementtree.ElementTree in Debian it's python-elementtree. What? As in, they renamed the module so it doesn't work? elementtree.ElementTree (xml.etree.ElementTree in = 2.5) is part of the core Python library, which is expected to be installed alongside Python. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #422: broken (d.)barscale
#422: broken (d.)barscale
--+-
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major| Milestone: 7.0.0
Component: Display | Version: svn-trunk
Resolution: |Keywords: cairo
Platform: Unspecified | Cpu: Unspecified
--+-
Comment (by glynn):
Replying to [comment:5 martinl]:
Not really, try
{{{
d.barscale -s
}}}
Different bug (D_poly*_rel() were broken). Should be fixed in r35276.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/422#comment:6
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
