On Tue, Oct 7, 2008 at 3:13 AM, Glynn Clements [EMAIL PROTECTED] wrote:
Rainer M Krug wrote:
I am trying to compile GRASS 6.3 from source, and am struggling with
the compilation of the modules r.in.gdal and r.out.gdal.
but the make results in:
Errors in:
[snip]
On Tue, 7 Oct 2008, Glynn Clements wrote:
Paul Kelly wrote:
main.cpp includes cmath; I wonder if the problem is due to the fact
isnan() is a C99 function? Should it be changed?
Yes. This came up about a month ago:
On Tue, Oct 7, 2008 at 11:53 AM, Paul Kelly
[EMAIL PROTECTED] wrote:
Are there any really huge files anybody can test it with?
For easily create a huge DEM file, do this:
SRTM V4 CGIAR Europe:
snip fetch_europe.sh -
#!/bin/sh
# fetch Europe block
#
I remember we replaced the fseek() with an fseeko() because we ran
into a bug where we were trying to seek to a large offset (in
r.terracost).
No objection to removing the 2 includes, given that it still compiles
w/o them on other platforms.
-Laura
On Oct 6, 2008, at 9:18 PM, [EMAIL
Glynn,
On Tue, Oct 7, 2008 at 12:02 PM, [EMAIL PROTECTED] wrote:
Author: glynn
Date: 2008-10-07 06:01:59 -0400 (Tue, 07 Oct 2008)
New Revision: 33717
Modified:
grass/trunk/lib/gis/null_val.c
Log:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
/me backport this?
On Mon, 6 Oct 2008, Hamish wrote:
Paul Kelly wrote:
I looked in r.in.xyz which only uses fseek() and
ISTR discussion about it handling huge files recently,
although perhaps that involved reading from stdin.
fwiw the fseek() there is just to grab the filesize so G_percent() can
know where
A few comments below.
On Oct 6, 2008, at 1:49 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Date: Mon, 6 Oct 2008 06:34:41 +0100
From: Glynn Clements [EMAIL PROTECTED]
Subject: Re: [GRASS-dev] porting r.in.wms to python
To: [EMAIL PROTECTED]
Cc: grass-dev grass-dev@lists.osgeo.org
(carrying over to grass-dev)
On Tue, Oct 7, 2008 at 8:40 PM, Frank Warmerdam [EMAIL PROTECTED] wrote:
Dylan Beaudette wrote:
Hi,
I am not sure if this is a DBF issue, or something deeper in OGR, but
there does not appear to be a mechanism for preserving 'nodata' or NULL
values when
Markus Neteler wrote:
Reviewing the mk_att() function in v.out.ogr's main.c I don't see
any effort to distinguish between null and non-null attributes so
I think the problem is just a limitation of v.out.ogr. If possible,
I'd suggest fixing it there.
Sounds good :)
Does anyone know how to fix
On Tue, 7 Oct 2008, Markus Neteler wrote:
On Tue, Oct 7, 2008 at 11:53 AM, Paul Kelly
[EMAIL PROTECTED] wrote:
Are there any really huge files anybody can test it with?
For easily create a huge DEM file, do this:
Actually, thinking clearly, it's a huge input text points file it needs.
So
Paul Kelly wrote:
+#ifdef HAVE_LARGEFILES
+ filesize = ftello(in_fp);
+#else
filesize = ftell(in_fp);
+#endif
Can we add library functions, G_fseek() and G_ftell(), which use an
off_t. The functions would use fseeko/ftello if available, fseek/ftell
otherwise, but would
Markus Neteler wrote:
Author: glynn
Date: 2008-10-07 06:01:59 -0400 (Tue, 07 Oct 2008)
New Revision: 33717
Modified:
grass/trunk/lib/gis/null_val.c
Log:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
/me backport this?
Maybe.
Unless there are modules
Michael Barton wrote:
d.rast.leg (d.frame)
(any thoughts Markus?)
perhaps replaced by some wxGUI load cartographic template tool?
(users could contribute their own etc..)
Note that it is possible to set a drawing frame by setting
GRASS_FRAME=t,b,l,r (see
Glynn:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
fwiw, I consider this a rare, but potentially very important change to
the raster engine.
Markus:
/me backport this?
Maybe.
Unless there are modules which genuinely need to distinguish GRASS
nulls from other NaNs,
Michael:
However, I suggested that matplotlib might be quite suitable for
this kind of task. It is a free, pure Python library that can do
very sophisticated graphing very easily.
a plus for matplotlib is that those of us who know Matlab plotting commands
quite well will already be trained in
Wouldn't it be interesting then to have G_is_[fd]_nan_value()?
2008/10/8 Hamish [EMAIL PROTECTED]:
Glynn:
Make G_is_[fd]_null_value() check for any NaN, not just all-ones
fwiw, I consider this a rare, but potentially very important change to
the raster engine.
Markus:
/me backport this?
Hi,
this change
http://trac.osgeo.org/grass/changeset/31236
introduced an unfortunate problem, whereas imported doubles have their
system level precision exposed (%.14f).
the general goal is that upon presentation by d.what.vect, v.db.select, or
whatever trailing 0s are nicely snipped away ala
17 matches
Mail list logo
