#73: r.out.gdal tiff output does not work
--+-
Reporter: helena| Owner: grass-...@…
Type: defect| Status: new
Priority: major |
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena| Owner: grass-...@…
Type: defect| Status: new
Priority: major |
#73: r.out.gdal tiff output does not work
-+--
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.1
#73: r.out.gdal tiff output does not work
-+--
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.5.0
#73: r.out.gdal tiff output does not work
-+--
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.5.0
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone:
#73: r.out.gdal tiff output does not work
-+--
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.5.0
Glynn Clements wrote:
Markus Metz wrote:
Considering this, rather use e.g. raster_min - 1 as default nodata value
for GDAL floating point datatypes?
If fabs(raster_min) is large, raster_min - 1 won't be exactly
representable, and may be rounded to raster_min. You would need to
subtract a
Glynn Clements wrote:
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,
Sorry, should have been nodata =
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone:
Markus Metz wrote:
Considering this, rather use e.g. raster_min - 1 as default nodata value
for GDAL floating point datatypes?
If fabs(raster_min) is large, raster_min - 1 won't be exactly
representable, and may be rounded to raster_min. You would need to
subtract a value which depends upon
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:
#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
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
Glynn Clements wrote:
Markus Metz wrote:
I think I slowly begin to understand. You suggest to use
(GDT_Int32)0x8000 for both the GDAL metadata info and the GDAL
raster data although GDAL metadata nodata is double?
Yes; for the latter, the value would be:
(double)
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.
Having -f affect the
Glynn Clements wrote:
Markus Metz wrote:
OK, but I have tested r.out.gdal with type = GDT_Int32 and nodata =
0x8000. Same result: NULL cells become -2147483648 but the nodata
value in the metadata says 2147483648 (gdalinfo on the export output),
Yes. I know. Running r.out.gdal ...
Markus Metz wrote:
OK, but I have tested r.out.gdal with type = GDT_Int32 and nodata =
0x8000. Same result: NULL cells become -2147483648 but the nodata
value in the metadata says 2147483648 (gdalinfo on the export output),
Yes. I know. Running r.out.gdal ... nodata=0x8000 is
Glynn Clements wrote:
Markus Metz wrote:
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 not have any data loss, be it due to
Markus Metz wrote:
That would also mean that r.out.gdal with type = GDT_Int32 and nodata =
2147483648, NULL cells become -2147483648 but the nodata value in the
metadata stays 2147483648 (gdalinfo on the export output), which in turn
means that other software, also QGIS, does not see
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
Markus Metz wrote:
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
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
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
Glynn Clements wrote:
Dylan Beaudette wrote:
3. Allow the user to specify what they would like NULL cells encoded as.
Unless I am overlooking something, it would seem reasonable to export a CELL
map to a signed integer format, and use some obvious negative value for NULL:
If you're
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone:
On 15/04/09 19:22, Dylan Beaudette wrote:
On Wednesday 15 April 2009, GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+
- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type:
defect |
On Wednesday 15 April 2009, Moritz Lennert wrote:
On 15/04/09 19:22, Dylan Beaudette wrote:
On Wednesday 15 April 2009, GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+-
--- - Reporter: helena |
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
Moritz Lennert wrote:
On 15/04/09 19:22, Dylan Beaudette wrote:
On Wednesday 15 April 2009, GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+
- Reporter: helena | Owner:
On Wed, 2009-04-15 at 18:30 +, GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Dylan Beaudette wrote:
3. Allow the user to specify what they would like NULL cells encoded as.
Unless I am overlooking something, it would seem reasonable to export a CELL
map to a signed integer format, and use some obvious negative value for NULL:
If you're exporting to a 32-bit (signed
On Wednesday 15 April 2009, Glynn Clements wrote:
Dylan Beaudette wrote:
3. Allow the user to specify what they would like NULL cells encoded as.
Unless I am overlooking something, it would seem reasonable to export a
CELL map to a signed integer format, and use some obvious negative value
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone:
On 30/10/08 08:02, GRASS GIS wrote:
Comment (by mmetz):
Yes, but for GeoTIFF these short colortables are not colortables in the
GeoTIFF sense, but custom metadata. The equivalent in gdal_translate would
be gdal_translate -mo COLOR_TABLE_RULE_0=... Qgis reads these rules
instead of the
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
On 24/10/08 14:10, Markus Metz wrote:
GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
On Oct 24, 2008, at 9:32 AM, Moritz Lennert wrote:
On 24/10/08 14:10, Markus Metz wrote:
GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--
+-
Reporter: helena | Owner:
On Friday 24 October 2008, Helena Mitasova wrote:
On Oct 24, 2008, at 9:32 AM, Moritz Lennert wrote:
On 24/10/08 14:10, Markus Metz wrote:
GRASS GIS wrote:
#73: r.out.gdal tiff output does not work
--
+-
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | 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:
#73: r.out.gdal tiff output does not work
---+
Reporter: helena| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
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: major|
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
#73: r.out.gdal tiff output does not work
--+-
Reporter: helena | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
78 matches
Mail list logo
