#565: r.colors: glibc double free or corruption with -ae
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: minor | Milestone:
#565: r.colors: glibc double free or corruption with -ae
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: minor | Milestone:
Glynn Clements wrote:
Markus Metz wrote:
so the user will have to understand the conversion issues even if they
never use an out-of-range value. Ultimately, its either usability or
flexibility.
Without the -f flag I would opt for usability, with the -f flag for
flexibility.
On 22/04/09 09:51, Markus Metz wrote:
Anyway, now I will stop defending a feature that I was never convinced
of (allowing this nodata mismatch). Can we now put together a next
version of r.out.gdal based on this discussion that always interprets
any user-given nodata value (with warning where
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone:
#498: r.sun2 out of sync / broken svn history
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
#376: v.generalize: index.c:153: RTreeInsertRect: Assertion
---+
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major |
#224: cache bug in DGLib
--+-
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
#456: Undefined references when building grass 6.4 rc4
+---
Reporter: fundawang | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major |
fyi, if we change dglib to use the G_* versions of malloc etc, then it
can't be used as a stand alone library anymore, as it is advertised to be.
http://grass.osgeo.org/dglib/
I'd note the the source code snapshot linked from that page hasn't been
updated since we made the switch from CVS.
#546: r.external support for SpatiaLite
--+-
Reporter: pcav | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major| Milestone:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone:
GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical
On Wed, Apr 22, 2009 at 1:30 PM, Hamish hamis...@yahoo.com wrote:
fyi, if we change dglib to use the G_* versions of malloc etc, then it
can't be used as a stand alone library anymore, as it is advertised to be.
Right.
http://grass.osgeo.org/dglib/
I'd note the the source code snapshot
Markus Metz wrote:
- all floating point: IEEE's NaN
Problem with NaN? According to IEEE 754, x == y is always FALSE if
either x or y or both are NaN. Assuming (nodata =
GDALGetRasterNoDataValue()) == NaN, then going through all cells if
(cell == nodata) will always be FALSE, nodata
#456: Undefined references when building grass 6.4 rc4
+---
Reporter: fundawang | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: reopened
Priority: major |
Hi All,
It is a novice question, I want to know how is the PostGreSQL used in
GRASS. My initial thought was that it stores the map attributes and
spatial information in PostGreSQL or similar databases. On the other
hand I also feel the dataset which GRASS uses to store map information
17 matches
Mail list logo
