Helena wrote:
where do the current somewhat broken items in nviz belong in your list,
I am talking about
1. fixing sites with attributes handling (I think Maris
has been looking into it but I am not sure how difficult it is
to fix it)
2. nviz crashing or freezing with reclassed raster (it
On Sun, Sep 13, 2009 at 12:35 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
I realized that there is something wrong with vector library in devbr6
and trunk, e.g.
$ v.random out=p1 n=1000 --o
...
Number of points: 1000
...
$ v.info p1 -t | grep points
points=1
Relbe64 seems to
On Sun, Sep 13, 2009 at 1:32 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Neteler wrote:
I have backported the relevant changes but I am unsure about
r39134, Attempt to determine message encoding on Windows [relevant for R]
I think that this should be back-ported. Otherwise, I
(for the record)
On Sat, Sep 5, 2009 at 8:55 PM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Neteler wrote:
@grass-dev: There are encoding issues with --interface-description
...
Apparently the Windows built was missing HAVE_LANGINFO_H or it
isn't properly set on Windows.
This
On Fri, Sep 11, 2009 at 5:25 PM, Georg Kaspar ge...@muenster.de wrote:
Dear GRASS developers,
Today I finished a first attempt at writing a GRASS script in python for
probabilistic label relaxation.
The script uses a given sigfile to run i.maxlik for _every_ given signature
and save the
Short note on nviz attributes - I suggest to NOT revert change that
broke this feature. I'm currently revriting attribute code, but I have
stuck in real life (work/family) and thus it will not be ready atleast
for next two weeks. It requires some redesign in OGSF, still I hope it
will be usefull
Glynn wrote:
These should be generated as part of the build process.
Otherwise, there's no guarantee that they actually match the colour
tables in lib/gis/colors
great, looks good.
One thing I notice is that in grass7 the D_move_abs(), D_cont_rel()
line widths are heavier than they were in
On Sep 12, 2009, at 12:21 PM, Benjamin Ducke wrote:
OpenCL can use CPUs and GPUs for parallel processing.
For all those operations that can be done more efficiently
on a GPU, there a potentially enormous performance gains.
Indeed. Precisely the reason why I think it is so compelling.
There
Glynn Clements wrote:
Markus Neteler wrote:
[...]
r39136, Fix diglib warnings
These mostly fix warnings related to Markus Metz' LFS changes, so
shouldn't be applicable to 6.4.
Thanks, I couldn't come up with something that works on both 32 bit and
64 bit. Interesting solution you
AFAIKT, r38992 Vect_get_num return long has no effect because the number
of features (for each type) is stored as plus_t which is int. If you
want to prepare the vector libs to support more than INT_MAX objects, I
would suggest to use
plus_t Vect_get_num_primitives(const struct Map_info *,
For the record, I'm trying to fix the bug in zooming beyond the poles
in latlon locations for TclTk. It's turned out to be more difficult
than I thought, but I'm making progress.
Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
Hi,
2009/9/13 Markus Metz markus.metz.gisw...@googlemail.com:
AFAIKT, r38992 Vect_get_num return long has no effect because the number of
features (for each type) is stored as plus_t which is int. If you want to
Right, I postponed this problem, thanks for raising it up.
prepare the vector
Helena,
On Wed, Aug 5, 2009 at 5:35 PM, Helena Mitasova hmit...@unity.ncsu.edu wrote:
Markus,
after some testing here,
it seems that the latest fixes in v.surf.rst submitted in dev_6 branch
(grass65) work
and if there are no objections they can be included in the GRASS64 release.
The
#82: grass would not start
---+
Reporter: timmie |Owner: osgeo4w-...@lists.osgeo.org
Type: defect | Status: reopened
Priority: major |Component: Installer
14 matches
Mail list logo
