Glynn,
Can you also put this important information into the WIKI programming
guide so that it doesn't get lost as easily?
Michael
On Aug 19, 2008, at 3:46 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Date: Tue, 19 Aug 2008 17:55:03 +0100
From: Glynn Clements [EMAIL PROTECTED]
Markus Metz wrote:
I have a wishlist for r.out.gdal together with a new version (link
below), and would like to put it up for discussion:
Changes in my version are:
Colortable export
A new flag -c is provided to export a colortable, default to no.
Colortables in GeoTIFF files are
On Tue, 19 Aug 2008, Marco Pasetti wrote:
Dear Robert,
How to run WinGRASS with non-english interface?
I tried different methods without success.
http://www.nabble.com/-GRASS5--Re%3A--GRASSLIST%3A5600--How-to-start-GRASS-in-another-language--p8590987.html
sincerely,
--
Robert Szczepanek
Markus Metz pisze:
Nodata value handling
If a nodata value was supplied, this value is tested whether it is
within the range of the selected data type and adjusted if necessary.
Specifying e.g. a nodata value of - and using Byte as data type
(range 0 - 255) is no longer accepted, it will
Glynn Clements pisze:
Markus Neteler wrote:
BTW, a r.external would be a great addition.
Yes, see:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt
Still not implemented... next GSoC project?
It's not that much work.
I have attached a first draft
Hi,
using d.rast.leg (d.legend) on a NO DATA integer map, it prints -2147483648
instead of null.
Below dirty hack cures the problem - how to do it correctly?
[EMAIL PROTECTED] d.legend]$ svn diff
Index: main.c
===
--- main.c
Maciej Sieczka wrote:
Markus Metz pisze:
Nodata value handling
If a nodata value was supplied, this value is tested whether it is
within the range of the selected data type and adjusted if necessary.
Specifying e.g. a nodata value of - and using Byte as data type
(range 0 - 255) is
Michael Barton wrote:
Can you also put this important information into the WIKI programming
guide so that it doesn't get lost as easily?
Okay:
http://grass.osgeo.org/wiki/Updating_GRASS_Documentation#A_brief_guide_to_valid_HTML
--
Glynn Clements [EMAIL PROTECTED]
Glynn Clements wrote:
BTW, a r.external would be a great addition.
Yes, see:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt
Still not implemented... next GSoC project?
It's not that much work.
I have attached a first draft patch which
Markus Neteler wrote:
using d.rast.leg (d.legend) on a NO DATA integer map, it prints -2147483648
instead of null.
Below dirty hack cures the problem - how to do it correctly?
After;
G_get_range_min_max(range, min_ind, max_ind);
add e.g.:
if (G_is_c_null_value(min_ind))
Markus Metz pisze:
Maciej Sieczka wrote:
I've noticed that r.out.gdal creates GeoTIFFs significantly larger than
gdal_translate. Could this be avoided?
Not completely, but file sizes are near identical (see below) in this
version:
Maciej Sieczka wrote:
I've noticed that r.out.gdal creates GeoTIFFs significantly larger than
gdal_translate. Could this be avoided?
Example, in spearfish60:
$ r.out.gdal in=landcover.30m out=landcover.30m.tif type=Byte
$ ls -l landcover.30m.tif
-rw-r--r-- 1 shoofi shoofi 303978
Glynn,
this is excellent! Thanks so much. I have tested it but no success yet:
On Wed, Aug 20, 2008 at 1:46 PM, Glynn Clements
[EMAIL PROTECTED] wrote:
Glynn Clements wrote:
BTW, a r.external would be a great addition.
It's not that much work.
...
Tomorrow, I'll look into creating an
On Wed, Aug 20, 2008 at 1:52 PM, Glynn Clements
[EMAIL PROTECTED] wrote:
Markus Neteler wrote:
using d.rast.leg (d.legend) on a NO DATA integer map, it prints -2147483648
instead of null.
Below dirty hack cures the problem - how to do it correctly?
After;
Glynn Clements pisze:
Maciej Sieczka wrote:
I've noticed that r.out.gdal creates GeoTIFFs significantly larger than
gdal_translate. Could this be avoided?
Example, in spearfish60:
$ r.out.gdal in=landcover.30m out=landcover.30m.tif type=Byte
$ ls -l landcover.30m.tif
-rw-r--r-- 1 shoofi
Markus Metz wrote:
r.out.gdal nodata handling could be changed so that the user has to
provide a nodata value if there are NULLs in the raster, otherwise
r.out.gdal aborts with an error.
That's reasonable for integer maps, but for FP maps it makes more
sense to simply default to NaN as the
Markus Neteler wrote:
this is excellent! Thanks so much. I have tested it but no success yet:
Tomorrow, I'll look into creating an r.external module, adding null
support, etc.
Okay, done (well, enough to try it out without having to manually hack
the files; null support is absent).
Glynn Clements wrote:
Known issues at present:
Null support is missing (r.external records any null value reported by
GDAL, but G_get_raster_row() etc ignore it; I suspect that it will
treat zero as null due to the absence of a null file).
Null support has been added.
The code which
I'm currently work on a python script that detects the epsg code of a
arbitrary GRASS location.
It scans the projection information of a GRASS location g.proj -j and
compares the output with the entries in /usr/share/proj/epsg file.
But there are significant differences between both parameter
On Wed, Aug 20, 2008 at 3:46 PM, Glynn Clements
[EMAIL PROTECTED] wrote:
Markus Neteler wrote:
this is excellent! Thanks so much. I have tested it but no success yet:
Tomorrow, I'll look into creating an r.external module, adding null
support, etc.
Okay, done (well, enough to try it
On Wednesday 20 August 2008, Glynn Clements wrote:
Markus Metz wrote:
r.out.gdal nodata handling could be changed so that the user has to
provide a nodata value if there are NULLs in the raster, otherwise
r.out.gdal aborts with an error.
That's reasonable for integer maps, but for FP maps
#263: wxgui: v.in.ascii's SQL column defintion text box is uneditable
--+-
Reporter: epatton | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
#263: wxgui: v.in.ascii's SQL column defintion text box is uneditable
--+-
Reporter: epatton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor|
#263: wxgui: v.in.ascii's SQL column defintion text box is uneditable
--+-
Reporter: epatton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: minor|
On Wed, Aug 20, 2008 at 5:34 PM, Markus Neteler [EMAIL PROTECTED] wrote:
On Wed, Aug 20, 2008 at 3:46 PM, Glynn Clements
[EMAIL PROTECTED] wrote:
Markus Neteler wrote:
...
Copied what over? r.external won't work unless the corresponding
lib/gis changes have also been incorporated, and lib/gis
Dylan Beaudette wrote:
On Wednesday 20 August 2008, Glynn Clements wrote:
Markus Metz wrote:
r.out.gdal nodata handling could be changed so that the user has to
provide a nodata value if there are NULLs in the raster, otherwise
r.out.gdal aborts with an error.
That's
On Wed, Aug 13, 2008 at 10:23 AM, Glynn Clements
[EMAIL PROTECTED] wrote:
Markus Neteler wrote:
Added as r.colors.out.
In trunk? Backported to develbranch_6?
Trunk.
It may need a G_find_cell2() call to work in 6.4. In 7.x, any libgis
functions which deal with existing maps should
Markus Metz wrote:
r.out.gdal nodata handling could be changed so that the user has to
provide a nodata value if there are NULLs in the raster, otherwise
r.out.gdal aborts with an error.
That's reasonable for integer maps, but for FP maps it makes more
sense to simply default
#64: ps.map: patch to set customized scalebar units
--+-
Reporter: alf | Owner: hamish
Type: enhancement | Status: assigned
Priority: minor| Milestone: 6.4.0
Component:
#91: ps.map doesn't remove .tmp files when it is done
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor|
30 matches
Mail list logo
