[GRASS-dev] Re: [GRASS GIS] #332: Uniform order for at= screen coordinates in d.* modules
#332: Uniform order for at= screen coordinates in d.* modules --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by glynn): Replying to [comment:1 hamish]: see comments in grass64.svn/lib/display/cnversions.c if you want to look deeper. Note: that file has changed a great deal in 7.0 (and may well change further), so don't pay too much attention to anything contained in it. In 7.0, the U coordinates aren't required to be cartographic coordinates, e.g. d.graph uses percentages (i.e. coordinates range from 0,0 to 100,100). Also, physical coordinates (pixels, points) are hardly used now by d.* commands. The only remaining vestige is that the conversion factor is often used for sizing text and certain other elements (e.g. symbols). -- Ticket URL: http://trac.osgeo.org/grass/ticket/332#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: is `initialized' initialized in HTML_Driver ()?
Ivan Shmakov wrote: Doesn't C require an explicit initial value for `initialized' here? Well, as it is a static variable it will be initialised to zero. Oh, never knew C has such a feature. (Still, it may make sense to add an explicit initializer for the sake of clarity.) If you add an explicit initialiser, the variable will be placed in the data segment. Variables which are implicitly initialised to zero (i.e. any global variables and static local variables lacking an explicit initialiser) are placed in the BSS segment. As the entire BSS segment is zero, its contents don't need to be stored in the resulting binary file. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: big region r.watershed
Hamish wrote: Markus Metz wrote: The original version uses very little memory, so assuming that GRASS runs today on systems where at least 500MB RAM are available I changed the parameters for the seg mode, more data are kept in memory, speeding up the seg mode. Looking at other modules using the segment library (e.g. v.surf.contour, r.cost), it seems that there is not one universally used setting, instead the segment parameters are tuned to each module. The new settings work for me, but not necessarily for others, and maybe using 500MB is a bit much. fwiw r.terraflow has a memory= option, the default is 300mb. AFAIU, the bigger you make that, the smaller the on-disk temp files need to be (ie work-around to keep tmp files 2gb for 32bit filesystems). a number of modules like r.in.poly have a rows= option, which I didn't really understand until I got into the code. (hold at most that many region rows (all columns) in memory at once). Interestingly the default value has scaled quite well over the years. and other modules like r.in.xyz have percent= (0-100) for how much of the map to keep in memory at once. A default value that scales well over the years would be preferable, but performance of r.watershed.fast -m is really poor if whole columns (or rows ) are kept in memory and much better if segments have equal dimensions. Interestingly, segments of 200 rows and 200 columns are processed fastest, faster than e.g. 150 rows and columns or 250 rows and columns. The more segments are kept in memory the better. Right now I don't want to introduce a new option to give the user control over how much memory is used (be it MB memory, number of rows or percent of the map) because I want to keep all options of r.watershed.fast identical to the original version. I'm still not happy with the speed of the segmented version of r.watershed.fast, but at least it is magnitudes faster than the in-memory version of the original r.watershed. Maybe the iostream library that came with r.terraflow can be used for r.waterhed -m as well. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: big region r.watershed
Markus Metz wrote: Right now I don't want to introduce a new option to give the user control over how much memory is used (be it MB memory, number of rows or percent of the map) because I want to keep all options of r.watershed.fast identical to the original version. adding new options is ok as it doesn't break compatibility. i.e. scripts written to use the old version will still run fine and produce the same output. only removing and renaming options is frozen for GRASS 6. (but ok in GRASS 7 aka trunk/) To gain access to the grass-addons SVN you will need to create yourself an OSGeo id and send the name to the grass-psc mailing list, along with a note that you have read and agree to RFC2. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.resamp.stats: nulls along western boundary
Hi, While running through this set of commands to resample from 30 to 2': http://grass.osgeo.org/wiki/Blue_Marble#Processing I notice that the output of r.resamp.stats has its western-most raster column set to all NULL. The other 3 borders seem to be ok. As the 30 data is without NULLs, and the target region is an exact multiple of the source region, it doesn't seem to be an inherent exceeding-the-border effect. The propagate nulls flag was not used. Besides losing data, when you zoom to look at the pacific it makes an ugly white line along 180W. ? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem compiling grass7
Martin Landa wrote: I'm not sure why it's failing in this particular case. I don't get any errors building that that file (or any other HTML file), pngdriver.html hasn't changed in over a month, and I checked for any broken HTML files within the last few days. Do you have any local modifications? no, to be sure I have downloaded fresh code from SVN. Now I am getting self.fmt(spec, content) File /home/martin/smetiste/grass_trunk/tools/g.html2man/g.html2man.py, line 229, in fmt (pre,sep,post) = format.partition(@) AttributeError: 'str' object has no attribute 'partition' I am using python 2.4. Are we going to require python = 2.5? Ah; the documentation says New in version 2.5. I've changed it to use split() instead. I don't know if there are any other 2.5-isms in there. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem compiling grass7
On Oct 13, 2008, at 1:52 AM, [EMAIL PROTECTED] wrote: Date: Mon, 13 Oct 2008 10:52:41 +0200 From: Martin Landa [EMAIL PROTECTED] Subject: Re: [GRASS-dev] problem compiling grass7 To: Glynn Clements [EMAIL PROTECTED] Cc: GRASS developers list grass-dev@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi, 2008/10/13 Glynn Clements [EMAIL PROTECTED]: I'm not sure why it's failing in this particular case. I don't get any errors building that that file (or any other HTML file), pngdriver.html hasn't changed in over a month, and I checked for any broken HTML files within the last few days. Do you have any local modifications? no, to be sure I have downloaded fresh code from SVN. Now I am getting self.fmt(spec, content) File /home/martin/smetiste/grass_trunk/tools/g.html2man/ g.html2man.py, line 229, in fmt (pre,sep,post) = format.partition(@) AttributeError: 'str' object has no attribute 'partition' I am using python 2.4. Are we going to require python = 2.5? I would strongly suggest it now. Tracking the release schedule of an actively developed language like Python is always a moving target, but as long as GRASS 7 is in development, I think we should try to do so within reason--because it will be much harder to do so once we have a stable GRASS 7. Python 2.6 is the current stable release and Python 3 is in beta. So I think we are still being amply conservative by requiring = 2.5. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.resamp.stats: nulls along western boundary
Hamish: While running through this set of commands to resample from 30 to 2': http://grass.osgeo.org/wiki/Blue_Marble#Processing I notice that the output of r.resamp.stats has its western-most raster column set to all NULL. The other 3 borders seem to be ok. As the 30 data is without NULLs, and the target region is an exact multiple of the source region, it doesn't seem to be an inherent exceeding-the-border effect. The propagate nulls flag was not used. Glynn: Can you come up with a recipe to reproduce this with the standard example data sets? sure: # lat/lon location g.region n=90N s=90S w=180W e=180E res=0:15 r.mapcalc fifteen=15 g.region res=1 r.resamp.stats in=fifteen out=fifteen.one r.univar fifteen.one ... total null cells: 180 g.region w=0 e=360 # center on 180 lon d.rast fifteen.one d.grid 90 -b color=black Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: is `initialized' initialized in HTML_Driver ()?
Glynn Clements [EMAIL PROTECTED] writes:
Doesn't C require an explicit initial value for `initialized' here?
Well, as it is a static variable it will be initialised to zero.
Oh, never knew C has such a feature. (Still, it may make sense to
add an explicit initializer for the sake of clarity.)
If you add an explicit initialiser, the variable will be placed in
the data segment.
Variables which are implicitly initialised to zero (i.e. any global
variables and static local variables lacking an explicit
initialiser) are placed in the BSS segment. As the entire BSS segment
is zero, its contents don't need to be stored in the resulting binary
file.
Is this behavior mandated by some standard?
It seems not a very smart decision to require such things. At
least, gcc does, in my opinion, the right thing and puts the
static variable initialized to zero (either explicitly or
implicitly) to BSS:
$ diff -u foo[12].c
--- foo1.c 2008-10-12 22:54:02.281519397 +0700
+++ foo2.c 2008-10-13 22:51:21.117012403 +0700
@@ -1,7 +1,7 @@
int
main ()
{
- static int a;
+ static int a = 0;
return a;
}
$ make CC=gcc foo1 foo2
gcc foo1.c -o foo1
gcc foo2.c -o foo2
$ nm foo1 | grep -F ' b '
005007c4 b a.1609
005007c0 b completed.5959
$ nm foo2 | grep -F ' b '
005007c4 b a.1609
005007c0 b completed.5959
$ diff -u (gcc -o - -S foo{1,2}.c)
--- /proc/self/fd/632008-10-13 22:59:42.420439493 +0700
+++ /proc/self/fd/622008-10-13 22:59:42.401668748 +0700
@@ -1,4 +1,4 @@
- .file foo1.c
+ .file foo2.c
.local a.1609
.comm a.1609,4,4
.text
$
Of course, if there are the compilers that produce different
results in these cases, it may make sense to leave the code in
its present state.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.resamp.stats: nulls along western boundary
Hamish wrote: While running through this set of commands to resample from 30 to 2': http://grass.osgeo.org/wiki/Blue_Marble#Processing I notice that the output of r.resamp.stats has its western-most raster column set to all NULL. The other 3 borders seem to be ok. As the 30 data is without NULLs, and the target region is an exact multiple of the source region, it doesn't seem to be an inherent exceeding-the-border effect. The propagate nulls flag was not used. Can you come up with a recipe to reproduce this with the standard example data sets? -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem compiling grass7
Hi, 2008/10/13 Glynn Clements [EMAIL PROTECTED]: I'm not sure why it's failing in this particular case. I don't get any errors building that that file (or any other HTML file), pngdriver.html hasn't changed in over a month, and I checked for any broken HTML files within the last few days. Do you have any local modifications? no, to be sure I have downloaded fresh code from SVN. Now I am getting self.fmt(spec, content) File /home/martin/smetiste/grass_trunk/tools/g.html2man/g.html2man.py, line 229, in fmt (pre,sep,post) = format.partition(@) AttributeError: 'str' object has no attribute 'partition' I am using python 2.4. Are we going to require python = 2.5? Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: big region r.watershed
Markus Metz wrote: Right now I don't want to introduce a new option to give the user control over how much memory is used (be it MB memory, number of rows or percent of the map) because I want to keep all options of r.watershed.fast identical to the original version. There's no reason to avoid adding new options, so long as you don't remove or modify existing options, and choose reasonable default behaviour in the case where the new option isn't used. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #333: v.out.ogr does not correctly encode NODATA in attribute tables
#333: v.out.ogr does not correctly encode NODATA in attribute tables --+- Reporter: dylan | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.4.0 Component: Vector| Version: svn-develbranch6 Keywords: v.out.ogr nodata |Platform: All Cpu: All | --+- v.out.ogr incorrectly exports tabular data containing NODATA values. Attached is a patch against GRASS64, as suggested by Roger Bivand / Frank W. -- Ticket URL: http://trac.osgeo.org/grass/ticket/333 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #329: Typo in i.oif.html and wording
#329: Typo in i.oif.html and wording --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: closed Priority: minor| Milestone: 6.4.0 Component: Docs | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by nikos): Great! Thank you :-) -- Ticket URL: http://trac.osgeo.org/grass/ticket/329#comment:11 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #329: Typo in i.oif.html and wording
#329: Typo in i.oif.html and wording --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: closed Priority: minor| Milestone: 6.4.0 Component: Docs | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by nikos): Replying to [comment:8 glynn]: Replying to [comment:7 nikos]: Apologies for the noise here. Hmmm... ? Why can't I attach the file and continue editing my post? You should be able to use the back button after submitting the file. At least Firefox remembers the state of any form elements if you go back to the page. Do you consider an extra button for that or, simpler, a message that states Thank you for the file submission. If wou wish you may continue editing/viewing your post by using the Back button of in your web- browser. ? :-p -- Ticket URL: http://trac.osgeo.org/grass/ticket/329#comment:12 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs
#334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs -+-- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: trivial | Milestone: 6.4.0 Component: Website | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- In section Revisit previous Diffs, after the code-box, it reads In the souce code Please change souce to source. -- Ticket URL: http://trac.osgeo.org/grass/ticket/334 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs
#334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: trivial | Milestone: Component: Website | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by martinl): * status: new = closed * resolution: = fixed * milestone: 6.4.0 = Comment: Fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/334#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs
#334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: trivial | Milestone: Component: Website | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by martinl): BTW, you can edit Trac wiki pages and fix these kind of typos by your own... -- Ticket URL: http://trac.osgeo.org/grass/ticket/334#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: is `initialized' initialized in HTML_Driver ()?
Ivan Shmakov wrote: Doesn't C require an explicit initial value for `initialized' here? Well, as it is a static variable it will be initialised to zero. Oh, never knew C has such a feature. (Still, it may make sense to add an explicit initializer for the sake of clarity.) If you add an explicit initialiser, the variable will be placed in the data segment. Variables which are implicitly initialised to zero (i.e. any global variables and static local variables lacking an explicit initialiser) are placed in the BSS segment. As the entire BSS segment is zero, its contents don't need to be stored in the resulting binary file. Is this behavior mandated by some standard? No. It seems not a very smart decision to require such things. At least, gcc does, in my opinion, the right thing and puts the static variable initialized to zero (either explicitly or implicitly) to BSS: Hmm; so it does. It didn't always; back in 2.x it would always put initialised variables in the data segment[1]. [1] This was quite important in the early days of the PlayStation, as there wasn't any run-time loader. It just read the executable directly into memory, so anything which ended up in the BSS segment would be left uninitialised. They eventually figured out how to disable the don't-store-the-contents-of-BSS behaviour, meaning that porting code from the PC didn't begin with a day spent adding = 0 everywhere. Of course, if there are the compilers that produce different results in these cases, it may make sense to leave the code in its present state. I wouldn't recommend adding explicit initialisers everywhere just in case people are unaware that they're not needed. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem compiling grass7
I am using python 2.4. Are we going to require python = 2.5? Michael: I would strongly suggest it now. Tracking the release schedule of an actively developed language like Python is always a moving target, but as long as GRASS 7 is in development, I think we should try to do so within reason--because it will be much harder to do so once we have a stable GRASS 7. I am not against requiring py2.5 for grass7, but if it costs us very little to stay backwards compatible with 2.4, then why not make the effort? Are the differences that great? Are we missing out on some huge advantage? Just because we may run the latest OSs, many others may not have upgraded in the last year, nor want to or are able to. Python 2.6 is the current stable release and Python 3 is in beta. So I think we are still being amply conservative by requiring = 2.5. for stability reasons, some of us like to run overly conservative systems. (cough debian cough) To make a dangerous over-generalization, the older feature set inherited from py2.4 will be much better tested and bug free than the latest gee-wiz fancy py2.6 features. And 2.4 is (just) 2 years old. It's not like arguing to support Tcl/Tk 8.0. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] problem compiling grass7
On Oct 13, 2008, at 4:45 PM, Hamish wrote: I am using python 2.4. Are we going to require python = 2.5? Michael: I would strongly suggest it now. Tracking the release schedule of an actively developed language like Python is always a moving target, but as long as GRASS 7 is in development, I think we should try to do so within reason--because it will be much harder to do so once we have a stable GRASS 7. I am not against requiring py2.5 for grass7, but if it costs us very little to stay backwards compatible with 2.4, then why not make the effort? Are the differences that great? Are we missing out on some huge advantage? Just because we may run the latest OSs, many others may not have upgraded in the last year, nor want to or are able to. Python 2.6 is the current stable release and Python 3 is in beta. So I think we are still being amply conservative by requiring = 2.5. for stability reasons, some of us like to run overly conservative systems. (cough debian cough) To make a dangerous over-generalization, the older feature set inherited from py2.4 will be much better tested and bug free than the latest gee-wiz fancy py2.6 features. And 2.4 is (just) 2 years old. It's not like arguing to support Tcl/Tk 8.0. My main concern is for future flexibility. Once GRASS 7 is actually released, it will be a lot harder to switch from 2.4 to 2.5. This means that if there are features in 2.5 that are useful, we won't be able to access them. It seems easier to try to keep as up-to-date as possible during development of this new version of GRASS so that we won't be numerous versions behind in dependencies like Python after it is released. It's not a guarantee, but most likely the things that were stable in 2.4 will still be stable in 2.5.2. FWIW, 2.6 is a stable version, not a development version. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs
#334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: trivial | Milestone: Component: Website | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by nikos): Pfff... though trac is only devs-only. Thanks. -- Ticket URL: http://trac.osgeo.org/grass/ticket/334#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs
#334: Minor typo in http://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: trivial | Milestone: Component: Website | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by nikos): I meant thought that trac is only for devs -- Ticket URL: http://trac.osgeo.org/grass/ticket/334#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] removing gis.m from GRASS 7
Michael wrote: The TclTk GUI is set to be abandoned in GRASS 7. It will continue to live in the GRASS 6 series. last call for objections before the Tcl/Tk gis.m is removed from GRASS 7. (trunk/gui/tcltk/) Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #335: export floats and doubles with correct precision
#335: export floats and doubles with correct precision
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: minor| Milestone: 6.4.0
Component: default | Version: unspecified
Keywords: precision|Platform: Unspecified
Cpu: Unspecified |
-+--
see http://thread.gmane.org/gmane.comp.gis.grass.devel/29622/
this started with lib/db/dbmi_base/valuefmt.c %lf - %.15g
High priority:
r.what, r.univar sum_str, r.info's fancy report min= max=, and r.colors.
Also 'g.region -g' - lib/gis/wind_format.c:
{{{
static int format_double(double value, char *buf)
{
sprintf(buf, %.8f, value);
G_trim_decimal(buf);
return 0;
}
}}}
I notice that raster/r.mapcalc/expression.c uses %.8g for a double.
for lat/lon, %.8f is approx 1mm (1852*60*1e-8; ie better than RTK GPS),
for meter/feet based units it's very very small.
I guess we may as well to do this properly, i.e. split off FCELL values to
something less precise ( %.6g, %f, ? ).
Maybe new G_format_double() and G_format_float() fns for that?
{{{
$ svngrep -r '%\.[1-9][0-9][fg]' * | cut -f1 -d: | uniq
display/d.rast.edit/edit.c
display/d.zoom/set.c
general/g.setproj/main.c
general/g.setproj/get_num.c
general/g.setproj/get_deg.c
lib/proj/convert.c
lib/proj/get_proj.c
lib/vector/rtree/gammavol.c
lib/vector/Vlib/intersect.c
lib/gis/quant_io.c
lib/gis/gislib.dox
lib/gis/proj3.c
lib/gis/color_write.c
lib/gis/cats.c
lib/g3d/g3dkeys.c
lib/g3d/writeascii.c
lib/g3d/filecompare.c
lib/g3d/g3dcats.c
lib/db/dbmi_base/datetime.c
lib/db/dbmi_base/valuefmt.c
ps/ps.map/ps_fclrtbl.c
raster/r.colors/rules.c
raster/r.stats/raw_stats.c
raster/r.univar2/stats.c
raster/r.reclass/main.c
raster/r.recode/read_rules.c
raster/r.info/main.c
raster/r.quant/read_rules.c
raster/r.distance/report.c
raster/r.cats/main.c
raster/r.external/main.c
raster/r.what/main.c
raster/r.statistics/o_average.c
raster/r.average/main.c
scripts/r.in.srtm/r.in.srtm
vector/v.to.points/main.c
vector/v.segment/main.c
vector/v.label.sa/main.c
vector/v.what.rast/main.c
vector/v.to.db/update.c
vector/v.to.db/report.c
vector/v.kernel/main.c
vector/v.in.ascii/points.c
}}}
the list is long and manual review is needed for each one.
Hamish
--
Ticket URL: http://trac.osgeo.org/grass/ticket/335
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
