Ha:
> > > > Also, "l" in XDRIVER fill is badly broken.
Gl:
> Duh; I spent about two hours looking over the culling algorithm
> before noticing that the problem with "l" is due to overflowing
> X's 16-coordinate range (16-bit signed short: -32768 to 32767).
>
> That issue effectively rules out usin
On 19/12/07 22:07, Michael Barton wrote:
Moritz,
Further testing grass has revealed an odd problem. It claims that there
is no tif support. However, we CAN make tifs using r.out.gdal (even
though not all Windows apps like them).
Nviz does not use gdal. It directly uses the tif libraries, but
Hamish wrote:
> > > next problem- r,d inverse fill a small bay upon zoom in.
> > > Also, "l" in XDRIVER fill is badly broken. "g" is correct in all
> > > cases. (the vector map for that section of coastline available upon
> > > request)
> > > http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2
Moritz,
Further testing grass has revealed an odd problem. It claims that
there is no tif support. However, we CAN make tifs using r.out.gdal
(even though not all Windows apps like them).
Michael
__
Michael Barton, Professor
Professor of Anthropology
Director of
Hamish wrote:
> but back to the d.vect rendering trials...
>
> H:
> > > The first is with spearfish's vector streams; adjusting 'd.vect
> > > width='
> ..
> > > XDRIVER: (for r,d,l width=1 polylines render poorly, as seem in
> > > original examples from quoted link at the top of this email.
> >
Hello,
I am trying to get openMP to explicitely run on an imagery module.
in the module Makefile I added this:
LIBES = $(GISLIB) -lgomp -fopenmp
to cover the lib requirements. and it seems to be fine while compiling the .o
files in OBJ.../ dir.
After a make install, the module parallel test cl
