Moritz Lennert wrote:
In the current state is there a possibility of using gdal's acceptance
of unvalid nodata ? And can we force a nodata value which exists in
the map ?
I would agree with Dylan that this kind of brute-force method should
remain possible, be it through the suggested -f fl
#560: WinGRASS not deleting temp ppm files from map display
---+
Reporter: isaacullah| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major
#561: meta: add a new "normal" bug priority
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone: Web
#560: WinGRASS not deleting temp ppm files from map display
--+-
Reporter: isaacullah| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major
On 17/04/09 16:53, Markus Metz wrote:
For r.out.gdal, there was discussion about not to override user options
and instead issue an error or a warning (going for error now) that the
nodata value is out of range. Currently, all default nodata values are
within the range of the selected GDAL data
#559: wingrass stand-alone installer: MSys console doesn't work
---+
Reporter: hamish| Owner: cnielsen
Type: defect| Status: assigned
Priority: minor | Milestone: 6.4.0
This is now a mix of r.in.gdal and r.out.gdal. The two modules
complement each other, and I guess a minimum requirement would be that
something exported with r.out.gdal and then imported again with
r.in.gdal should be identical (taking into consideration the region
settings during export) and n
#559: wingrass stand-alone installer: MSys console doesn't work
---+
Reporter: hamish| Owner: cnielsen
Type: defect| Status: assigned
Priority: minor | Milestone: 6.4.0
Glynn Clements wrote:
Markus Metz wrote:
I remember a discussion in the dev ml, I think with the osgeo4w
installer, that memory allocated with malloc/calloc/realloc should be
free-d with free, not G_free. If this is the case, then there is a
problem in the vector libs, because space for a
On Apr 17, 2009, at 4:24 AM, Markus Neteler wrote:
No problem, looks fine.
It seems to be Mac specific.
Yes, it's a Mac problem. Something that changed in OSX 10.5.
And I get the following repeated a whole bunch of times:
The process has forked and you cannot use this CoreFoundation
func
10 matches
Mail list logo
