#660: v.delaunay producing incorrect results
---+
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.5.0
Hi list,
I created a wiki-article where logos of the numerous OSGeo projects can
be linked.
The reason for creating the page: last week I wasted hours to get logos
of most of the OSGeo projects in printquality to arrange them on a
poster for the Linxtag in Berlin. All OSGeo projects: please
#660: v.dalaunay producing incorrect results
---+
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.5.0
Hi,
I have been watching some fork()ed processes in top+grellm on a multicore
CPU (linux). It seems that both the display driver (6.5svn d.vect
+XDRIVER) and DB driver (v.in.ascii+DBF) both fork() a child process, but
these remain bound to the same core as the parent.
especially for v.in.ascii+db
Hamish wrote:
> why was #include added to this file:
>
> .../vector/lidar/lidarlib/TcholBand.c...
>
>
> I'm assuming there are other false positives.
I'm wondering if Martin just added Rast.h to every file which included
gis.h.
I see 294 cases which appear to be false positives (files which
#659: probable memory leak in v.surf.bspline
+---
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Miles
2009/6/22 Hamish :
>
> Yann Chemin wrote:
>> Made a map in Australia, and wanted to use r.horizon on it.
>> Nothing special, a srtm map and default conditions.
>> This is the output:
>>
>> (Sat Jun 20 16:51:57 2009)
>> r.horizon elevin=dem...@permanent horizonstep=30 bufferzone=200
>> maxdistance
Yann Chemin wrote:
> Made a map in Australia, and wanted to use r.horizon on it.
> Nothing special, a srtm map and default conditions.
> This is the output:
>
> (Sat Jun 20 16:51:57 2009)
> r.horizon elevin=dem...@permanent horizonstep=30 bufferzone=200
> maxdistance=2000 horizon=horangle
> G_s
