Re: [GRASS-dev] bug in v.db.renamecol [was: Re: [GRASS-user] Rename multiple sqlite columns at once]
On 19/11/08 02:49, Hamish wrote: I would suggest like: oldcoltype=`db.describe -c table=$table database=$database driver=$driver | grep -w $oldcol | cut -d':' -f3` - always quote variables which could contain spaces (even in error). - use grep -w to only look for words, not strings Committed as such. Thanks for the tip ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] g.mlist: exclude parameter wish
Hi, would it be complicated to add an exclude_pattern parameter to g.mlist/g.mremove? Example: I want to select only the gpcp_1dd_p1d_*_count maps but not the monthly counts: g.mlist type=rast patt=gpcp_1dd_p1d_*_count gpcp_1dd_p1d_1997_2007_month04_10_count gpcp_1dd_p1d_1997_count gpcp_1dd_p1d_1997_month04_10_count gpcp_1dd_p1d_1998_count gpcp_1dd_p1d_1998_month04_10_count gpcp_1dd_p1d_1999_count gpcp_1dd_p1d_1999_month04_10_count gpcp_1dd_p1d_2000_count gpcp_1dd_p1d_2000_month04_10_count gpcp_1dd_p1d_2001_count gpcp_1dd_p1d_2001_month04_10_count gpcp_1dd_p1d_2002_count gpcp_1dd_p1d_2002_month04_10_count gpcp_1dd_p1d_2003_count gpcp_1dd_p1d_2003_month04_10_count gpcp_1dd_p1d_2004_count gpcp_1dd_p1d_2004_month04_10_count gpcp_1dd_p1d_2005_count gpcp_1dd_p1d_2005_month04_10_count gpcp_1dd_p1d_2006_count gpcp_1dd_p1d_2006_month04_10_count gpcp_1dd_p1d_2007_count gpcp_1dd_p1d_2007_month04_10_count Wish (ideal world): g.mlist type=rast patt=gpcp_1dd_p1d_*_count exclude=month gpcp_1dd_p1d_1997_count gpcp_1dd_p1d_1998_count gpcp_1dd_p1d_1999_count gpcp_1dd_p1d_2000_count gpcp_1dd_p1d_2001_count gpcp_1dd_p1d_2002_count gpcp_1dd_p1d_2003_count gpcp_1dd_p1d_2004_count gpcp_1dd_p1d_2005_count gpcp_1dd_p1d_2006_count gpcp_1dd_p1d_2007_count I know that -r and -e are available but I failed to write an exclusion regex. And often just simple patterns are to be suppressed in the selection. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #368: g.mkfontcap: extradirs=path seems to fail
#368: g.mkfontcap: extradirs=path seems to fail --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: svn-trunk Resolution: fixed|Keywords: fonts Platform: Linux| Cpu: x86-64 --+- Changes (by neteler): * status: new = closed * resolution: = fixed Comment: I have added the warning in r34387 and r34388. -- Ticket URL: http://trac.osgeo.org/grass/ticket/368#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
Re: [GRASS-dev] g.mlist: exclude parameter wish
On Wed, Nov 19, 2008 at 10:51 AM, Paul Kelly [EMAIL PROTECTED] wrote: Hi Markus On Wed, 19 Nov 2008, Markus Neteler wrote: Hi, would it be complicated to add an exclude_pattern parameter to g.mlist/g.mremove? Example: I want to select only the gpcp_1dd_p1d_*_count maps but not the monthly counts: g.mlist type=rast patt=gpcp_1dd_p1d_*_count What about g.mlist type=rast patt=gpcp_1dd_p1d__count bingo :) I think that should work with a shell script version of g.mlist anyway, as ? characters can be used to represent single characters in wildcard patterns passed to the ls command. This works, resolved for today. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] opencell opening temp null file: no temp files available
Hello, I am writing a Grass programm which creates a raster, reads the values of the raster map at certain points and creates a new rastermap having the same name as the old one. I am using the function G_open_cell_new() to overwrite the existing raster map. and the function G_close_cell() It works fine. But after about 1000 loops I get the following messsage. WARNING: opencell opening temp null file: no temp files available Does anyone know what it means. I have enough space left in my ./tmp folder. And I also have write permissions on it. Thanks in advance. Andi -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist: exclude parameter wish
Markus wrote: g.mlist type=rast patt=gpcp_1dd_p1d_*_count exclude=month gpcp_1dd_p1d_1997_count gpcp_1dd_p1d_1998_count gpcp_1dd_p1d_1999_count gpcp_1dd_p1d_2000_count gpcp_1dd_p1d_2001_count gpcp_1dd_p1d_2002_count gpcp_1dd_p1d_2003_count gpcp_1dd_p1d_2004_count gpcp_1dd_p1d_2005_count gpcp_1dd_p1d_2006_count gpcp_1dd_p1d_2007_count I know that -r and -e are available but I failed to write an exclusion regex. And often just simple patterns are to be suppressed in the selection. no idea about the C version, but with the shell script version it would be roughly like if [ -n $GIS_OPT_EXCLUDE ] ; then EXCLD_STR=| grep -v $GIS_OPT_EXCLUDE else EXCLD_STR= fi g.list * ... | ... $EXCLD_STR do you now use g.mlist | grep -v 'expr' ? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #35: Verify and uncomment Swiss datum parameters
#35: Verify and uncomment Swiss datum parameters --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by swisstopoum): * platform: = Unspecified * cpu: = Unspecified Comment: CH1903 and CH1903+ are basically the same system (only defined a little bit differently). The problem is only the realisation of the system (CH1903/LV03 by triangulation ; CH1903+/LV95 by GPS). The differences between the 2 systems are in the order of 1.5 m in maximum. Today we don't recommend the use of the 7 parameter transform any more. So please - whenever possible - don't use them. For the transformation from CH1903+ to ETRS89 we use officially the following 3 parameters: dX=674.374 m, dY=15.056 m; dZ=405.346 m. If necessary, you can model the differences between CH1903+ and CH1903 with a distortion grid in the NTv2 format. This grid can be downloaded here: [http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/ lv03-lv95/chenyx06/distortion_grids.html] More information on the Swiss system and projection can be found here: [http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys/refsys.parsysrelated1.2487.downloadList.78978.DownloadFile.tmp/swissprojectionen.pdf] In this document you find all the necessary formulas and parameters - as well as some examples. I revised this document in the meantime - but could not put it on the web yet. It contains some more explanations and more complete examples. Look for the revision date of the document: It should be 'october 2008'. If you need it right now, please contact me. Urs -- Ticket URL: http://trac.osgeo.org/grass/ticket/35#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
[GRASS-dev] r34362, r34366
Hi, re. area of https://trac.osgeo.org/grass/changeset/34362 is it really a good idea for us to be telling people to use rm -rf in a main help page?? For one thing it's not portable, and for another new users are reading that- I'd suggest for them to learn to do dangerous things on their own time and we just say nothing. They'll all know how to delete a folder, all we have to say is that they can do that without worrying about breaking some registry. but let them source their own ammo. re. https://trac.osgeo.org/grass/changeset/34366 fine for grass7, but please don't disable valid+working functionality in devbr6. if you want to launch a gui window for it use r.recode --ui. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist: exclude parameter wish
On Wed, Nov 19, 2008 at 11:12 AM, Hamish [EMAIL PROTECTED] wrote: Markus wrote: g.mlist type=rast patt=gpcp_1dd_p1d_*_count exclude=month gpcp_1dd_p1d_1997_count gpcp_1dd_p1d_1998_count gpcp_1dd_p1d_1999_count gpcp_1dd_p1d_2000_count gpcp_1dd_p1d_2001_count gpcp_1dd_p1d_2002_count gpcp_1dd_p1d_2003_count gpcp_1dd_p1d_2004_count gpcp_1dd_p1d_2005_count gpcp_1dd_p1d_2006_count gpcp_1dd_p1d_2007_count I know that -r and -e are available but I failed to write an exclusion regex. And often just simple patterns are to be suppressed in the selection. no idea about the C version, but with the shell script version it would be roughly like if [ -n $GIS_OPT_EXCLUDE ] ; then EXCLD_STR=| grep -v $GIS_OPT_EXCLUDE else EXCLD_STR= fi g.list * ... | ... $EXCLD_STR Yes - but I dunno how to implement that in C. do you now use g.mlist | grep -v 'expr' ? g.mlist type=rast patt=gpcp_1dd_p1d_*_count | grep -v month | tr '\n' ',' | sed 's+,$++g but that's rather funky for daily usage. [for today, Paul's trick helped but the problem will return] Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] bug in v.db.renamecol [was: Re: [GRASS-user] Rename multiple sqlite columns at once]
Moritz wrote:
Don't think that table names can have spaces
it doesn't matter if they can really have spaces, it matters if a user who
thinks they could have spaces tries that. The goal is that the module
does not fail in a bizzare way in that case, but with a useful error
message from the correct place.
if modules are run live from the web, an unquoted variable could include
something like table=dbf; run_evil_command; #, and without quoting
they have all the shell access they want. (well, I'm not totally sure
about that, but it scares me enough to be pedantic about it for shell
scripts)
Hamish
ps- ${var} is a little overkill, I think $var is fine. and I'm not
sure if around VAR=`` is needed, or if that causes problems if interior
command also contains . ??
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] bug in v.db.renamecol [was: Re: [GRASS-user] Rename multiple sqlite columns at once]
On 19/11/08 13:35, Hamish wrote:
Moritz wrote:
Don't think that table names can have spaces
it doesn't matter if they can really have spaces, it matters if a user who
thinks they could have spaces tries that. The goal is that the module
does not fail in a bizzare way in that case, but with a useful error
message from the correct place.
But the user does not define table name in v.db.renamecol. The module
takes the table linked to a map.
if modules are run live from the web, an unquoted variable could include
something like table=dbf; run_evil_command; #, and without quoting
they have all the shell access they want. (well, I'm not totally sure
about that, but it scares me enough to be pedantic about it for shell
scripts)
Don't know if a combination of v.db.connect -o with evil table name
followed by v.db.renamecol could cause trouble like that.
ps- ${var} is a little overkill, I think $var is fine. and I'm not
sure if around VAR=`` is needed, or if that causes problems if interior
command also contains . ??
I'll leave this to the specialists. There's tons of examples of that
usage of quotes in the scripts...
I'll just do as I'm told ;-)
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist: exclude parameter wish
Hi Markus On Wed, 19 Nov 2008, Markus Neteler wrote: Hi, would it be complicated to add an exclude_pattern parameter to g.mlist/g.mremove? Example: I want to select only the gpcp_1dd_p1d_*_count maps but not the monthly counts: g.mlist type=rast patt=gpcp_1dd_p1d_*_count What about g.mlist type=rast patt=gpcp_1dd_p1d__count I think that should work with a shell script version of g.mlist anyway, as ? characters can be used to represent single characters in wildcard patterns passed to the ls command. Paul gpcp_1dd_p1d_1997_2007_month04_10_count gpcp_1dd_p1d_1997_count gpcp_1dd_p1d_1997_month04_10_count gpcp_1dd_p1d_1998_count gpcp_1dd_p1d_1998_month04_10_count gpcp_1dd_p1d_1999_count ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] opencell opening temp null file: no temp files available
[EMAIL PROTECTED] wrote: I am writing a Grass programm which creates a raster, reads the values of the raster map at certain points and creates a new rastermap having the same name as the old one. I am using the function G_open_cell_new() to overwrite the existing raster map. and the function G_close_cell() It works fine. But after about 1000 loops I get the following messsage. WARNING: opencell opening temp null file: no temp files available Does anyone know what it means. I have enough space left in my ./tmp folder. And I also have write permissions on it. It probably means that files aren't getting closed, so you are exceeding the limit on the number of open files per process (by default 1024, check with ulimit -n). On Linux, you can check which files a process has open by looking in the /proc/pid/fd directory, where pid is the PID of the process. If you're modifying a map in-place, you'll need to close and re-open the input map in order to see the changes. Opening a map for write creates a temporary file, which is renamed over the original when closed. If the original cell/fcell file is still open for read at that point, it will still exist and still be open (it will show up as (deleted) in /proc/pid/fd). -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] bug in v.db.renamecol [was: Re: [GRASS-user] Rename multiple sqlite columns at once]
Hamish wrote: Don't think that table names can have spaces it doesn't matter if they can really have spaces, it matters if a user who thinks they could have spaces tries that. The goal is that the module does not fail in a bizzare way in that case, but with a useful error message from the correct place. if modules are run live from the web, an unquoted variable could include something like table=dbf; run_evil_command; #, and without quoting they have all the shell access they want. (well, I'm not totally sure about that, but it scares me enough to be pedantic about it for shell scripts) If modules are run live from the web, there are plenty of other problems to worry about (buffer overflows, system(), etc). A web interface would need to validate all input using a default-deny approach, i.e. define what consitutes valid input and reject everything else. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] (no subject)
It seems that the files are not closed, but I use if((elev_fd = G_open_cell_old (name, mapset)) 0) G_fatal_error( _(can't open %s), name); if((output_fd = G_open_cell_new(outname)) 0) G_fatal_error( _(can't open outname %s), outname); to open the files and G_close_cell(output_fd); G_close_cell(elev_fd); to close the files again. Is there anything wrong? Andi Glynn Clements wrote: [EMAIL PROTECTED] wrote: I am writing a Grass programm which creates a raster, reads the values of the raster map at certain points and creates a new rastermap having the same name as the old one. I am using the function G_open_cell_new() to overwrite the existing raster map. and the function G_close_cell() It works fine. But after about 1000 loops I get the following messsage. WARNING: opencell opening temp null file: no temp files available Does anyone know what it means. I have enough space left in my ./tmp folder. And I also have write permissions on it. It probably means that files aren't getting closed, so you are exceeding the limit on the number of open files per process (by default 1024, check with ulimit -n). On Linux, you can check which files a process has open by looking in the /proc/pid/fd directory, where pid is the PID of the process. If you're modifying a map in-place, you'll need to close and re-open the input map in order to see the changes. Opening a map for write creates a temporary file, which is renamed over the original when closed. If the original cell/fcell file is still open for read at that point, it will still exist and still be open (it will show up as (deleted) in /proc/pid/fd). -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] opencell opening temp null file: no temp files available
It seems that the files are not closed, but I use if((elev_fd = G_open_cell_old (name, mapset)) 0) G_fatal_error( _(can't open %s), name); if((output_fd = G_open_cell_new(outname)) 0) G_fatal_error( _(can't open outname %s), outname); to open the files and G_close_cell(output_fd); G_close_cell(elev_fd); to close the files again. Is there anything wrong? Andi Glynn Clements wrote: [EMAIL PROTECTED] wrote: I am writing a Grass programm which creates a raster, reads the values of the raster map at certain points and creates a new rastermap having the same name as the old one. I am using the function G_open_cell_new() to overwrite the existing raster map. and the function G_close_cell() It works fine. But after about 1000 loops I get the following messsage. WARNING: opencell opening temp null file: no temp files available Does anyone know what it means. I have enough space left in my ./tmp folder. And I also have write permissions on it. It probably means that files aren't getting closed, so you are exceeding the limit on the number of open files per process (by default 1024, check with ulimit -n). On Linux, you can check which files a process has open by looking in the /proc/pid/fd directory, where pid is the PID of the process. If you're modifying a map in-place, you'll need to close and re-open the input map in order to see the changes. Opening a map for write creates a temporary file, which is renamed over the original when closed. If the original cell/fcell file is still open for read at that point, it will still exist and still be open (it will show up as (deleted) in /proc/pid/fd). -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] opencell opening temp null file: no temp files available
Hello!
I found out that it has nothing to do with my open and closed cell files
I must be something in my reproject function.
I read in some points (2000) and each point is transformed to lat/lang using
following function
void transfform_lat(double longitude, double latitude){
struct Key_Value *in_proj_info, *in_unit_info;
struct pj_info iproj;
struct pj_info oproj;
...
...
...
if ((in_proj_info = G_get_projinfo()) == NULL)
G_fatal_error(Can't get projection info of current location);
if ((in_unit_info = G_get_projunits()) == NULL)
G_fatal_error(Can't get projection units of current location);
if (pj_get_kv(iproj, in_proj_info, in_unit_info) 0)
G_fatal_error(Can't get projection key values of current
location);
G_free_key_value( in_proj_info );
G_free_key_value( in_unit_info );
/* set output projection to lat/long for solpos*/
oproj.zone = 0;
oproj.meters = 1.;
sprintf(oproj.proj, ll);
if ((oproj.pj = pj_latlong_from_proj(iproj.pj)) == NULL)
G_fatal_error(Unable to set up lat/long projection
parameters);
if(pj_do_proj(longitude, latitude, iproj, oproj) 0)
{
fprintf(stderr,Error in pj_do_proj (projection of input coordinate
pair)\n);
exit(0);
}
..
}
After 1024 projections the programm stops.
When I have a look in /proc/pid/fd/
I can see the following:
...
...
...
lr-x-- 1 andi andi 64 2008-11-19 16:21 66 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 67 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 68 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 69 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:19 7 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 70 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 71 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 72 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 73 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 74 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 75 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 76 -
/usr/local/grass-6.3.0/etc/ellipse.table
...
Does anybody know how to solve the problem
Thanks.
Andi
Glynn Clements wrote:
[EMAIL PROTECTED] wrote:
I am writing a Grass programm which creates a raster, reads the values
of the raster map at certain points and creates a new rastermap having
the same name as the old one.
I am using the function
G_open_cell_new() to overwrite the existing raster map.
and the function
G_close_cell()
It works fine.
But after about 1000 loops I get the following messsage.
WARNING: opencell opening temp null file: no temp files available
Does anyone know what it means. I have enough space left in my ./tmp
folder. And I also have write permissions on it.
It probably means that files aren't getting closed, so you are
exceeding the limit on the number of open files per process (by
default 1024, check with ulimit -n).
On Linux, you can check which files a process has open by looking in
the /proc/pid/fd directory, where pid is the PID of the process.
If you're modifying a map in-place, you'll need to close and re-open
the input map in order to see the changes. Opening a map for write
creates a temporary file, which is renamed over the original when
closed. If the original cell/fcell file is still open for read at that
point, it will still exist and still be open (it will show up as
(deleted) in /proc/pid/fd).
-- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen
downloaden: http://www.gmx.net/de/go/browser
-- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen:
http://www.gmx.net/de/go/topmail
___ grass-dev mailing list
grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r34362, r34366
Hi, 2008/11/19 Hamish [EMAIL PROTECTED]: re. https://trac.osgeo.org/grass/changeset/34366 fine for grass7, but please don't disable valid+working functionality in devbr6. if you want to launch a gui window for it use r.recode --ui. well, I prefer to disable GRASS_UI_TERM in general (where is possible). But maybe you are right (in terms of g6.x), if you prefer I will revert this change. M. -- 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] opencell opening temp null file: no temp files available
Andi Jochem wrote:
I found out that it has nothing to do with my open and closed cell files
I must be something in my reproject function.
I read in some points (2000) and each point is transformed to lat/lang using
following function
void transfform_lat(double longitude, double latitude){
struct Key_Value *in_proj_info, *in_unit_info;
struct pj_info iproj;
struct pj_info oproj;
...
...
...
if ((in_proj_info = G_get_projinfo()) == NULL)
G_fatal_error(Can't get projection info of current location);
if ((in_unit_info = G_get_projunits()) == NULL)
G_fatal_error(Can't get projection units of current location);
if (pj_get_kv(iproj, in_proj_info, in_unit_info) 0)
G_fatal_error(Can't get projection key values of current
location);
G_free_key_value( in_proj_info );
G_free_key_value( in_unit_info );
/* set output projection to lat/long for solpos*/
oproj.zone = 0;
oproj.meters = 1.;
sprintf(oproj.proj, ll);
if ((oproj.pj = pj_latlong_from_proj(iproj.pj)) == NULL)
G_fatal_error(Unable to set up lat/long projection
parameters);
You shouldn't be doing this for each point. Do it once, and keep iproj
and oproj around.
After 1024 projections the programm stops.
When I have a look in /proc/pid/fd/
I can see the following:
...
...
...
lr-x-- 1 andi andi 64 2008-11-19 16:21 66 -
/usr/local/grass-6.3.0/etc/ellipse.table
lr-x-- 1 andi andi 64 2008-11-19 16:21 67 -
/usr/local/grass-6.3.0/etc/ellipse.table
[snip]
This looks like a GRASS bug.
read_ellipsoid_table() in lib/proj/ellipse.c never closes the file.
You can fix it with:
--- lib/proj/ellipse.c (revision 31109)
+++ lib/proj/ellipse.c (working copy)
@@ -264,6 +264,9 @@
continue;
}
}
+
+fclose(fd);
+
if (!err)
return outputlist;
This has been fixed in 6.4/7.0.
read_ellipsoid_table() in lib/gis/get_ellipse.c has the same issue
(which I've now fixed). However, that function checks whether the
table has already been read, and returns immediately if it has, so it
never opens the file more than once.
I suspect the lib/proj version should do something similar. In fact,
it should probably use the code in lib/gis.
--
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] #370: nviz_cmd produces images with 1 pixel size
#370: nviz_cmd produces images with 1 pixel size
---+
Reporter: jachym | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor | Milestone:
Component: NVIZ | Version: svn-trunk
Keywords: commandline, nviz_cmd |Platform: Linux
Cpu: x86-32 |
---+
Testing new nviz_cmd, it produces only image of 1x1 size:
{{{
GRASS 7.0.svn (spearfish60):~ nviz_cmd color_map=elevation.dem
elevation_map=elevation.dem output=image
Loading raster map [EMAIL PROTECTED]...
Loading raster map [EMAIL PROTECTED]...
Translating colors from raster map [EMAIL PROTECTED]...
Vertical exaggeration not given, using calculated value 1
Viewpoint height not given, using calculated value 10561
nviz_cmd complete. File image.ppm created.
GRASS 7.0.svn (spearfish60):~ identify image.ppm
image.ppm PNM 1x1 1x1+0+0 DirectClass 8-bit 14b
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/370
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] #371: wxGUI: can't render layer different than 1
#371: wxGUI: can't render layer different than 1 --+- Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Keywords:|Platform: All Cpu: All | --+- 1. add any vector map with more than one layer 2. you can't select which layer to render - neither at load time, nor later in properties -- Ticket URL: http://trac.osgeo.org/grass/ticket/371 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-user] how to measure distances in a constrained space
Glynn Clements wrote: In any case, the specific purpose of r.grow.distance is: r.grow.distance generates a raster map representing the distance to the nearest non-null cell in the input map. It now has an additional function: to generate a raster map containing the value of the nearest cell. From this, it is possible to mimic the behaviour of r.grow, but substantially faster, with e.g.: # equivalent to: r.grow input=$inmap output=$outmap radius=$radius metric=$metric temp=r.grow.tmp.$$ r.grow.distance in=$inmap distance=$temp.dist value=$temp.near metric=$metric r.mapcalc $outmap = if($temp.dist $radius,$temp.near,null()) r.colors $outmap rast=$temp.near g.remove rast=$temp.dist,$temp.near Whereas the worst-case time taken by r.grow is proportional to the square of the buffer radius, the above is proportional only to the area of the map, regardless of the buffer radius. I'll replace r.grow in 7.0 with a script along these lines. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: raster modules still using sites library
I figured out what the 'problem' is with r.walk. If you use a null map for the friction map (because a friction map is required even if you don't want to use it), it creates raster support files but no map (i.e., no cell/fcell map). This is a minor bug as it should either give an error or create something (null map, ignore the friction map, but something). But it is an easy workaround and is not critical. Still, people should be aware of this. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Nov 18, 2008, at 12:31 PM, Michael Barton wrote: Thanks Colin, I'll need to try more to see what is going on. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Nov 18, 2008, at 12:26 PM, Colin Nielsen wrote: I'm not sure what version you are using but those modules run fine for me using a vector file, with multiple points (I've been using v6.3 compiled in windows with msys/mingw). They just put up a warning message about the sites library being deprecated. Honestly, I attempted but failed to update r.walk to the vector library. My programming skills are not quite up to par, yet. -Colin On Tue, Nov 18, 2008 at 2:17 PM, Michael Barton [EMAIL PROTECTED] wrote: For several years now, r.cost, r.drain, and now r.walk have continued to use the adapted sites library instead of the vector library. This means that they all fail if you enter vector points as starting points. It sure would be nice if this feature actually worked on these so that you could 1) use a vector map for start points rather than having to manually enter coordinates and 2) use multiple starting points. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.drain cumulative flag
In working with r.drain to create a least-cost path map, it seems that the -c flag creates a path with cumulative values, but not one that I can see is usable for anything. What happens now is that starting at the beginning of the path, each cell adds the underlying cost surface (or elevation for a drainage map) value to the value of the preceding cell in the path. At the end, the last cell has a value of the sum of all the cost (or elevation) values between the start and the end. So for a path traversing cells of the following values... 300 | 200 | 100 | 0 The path cells would have the values... 300 | 500 | 600 | 600 This is indeed a cumulative cost, but not one that is useful for anything I can think of. What would be much more useful if each cell calculated the difference between the current cost value and the preceding one and added that to the preceding path value. For the cost surface above, the result would be... 0 | 100 | 200 | 300 This gives the actual cost of traversing the path at any point along the path and the total cost at the end. Note that this is different than just copying the underlying cost value into the path if the path is not a straight line. Any interest in changing the behavior of -c or maybe making a -t (total) flag? Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mlist: exclude parameter wish
Markus, We could add the exclude option, but I'm not so sure if we really need it. You can solve your problem by using a more specific wildcard if Paul's trick doesn't work. pat=gpcp_1dd_p1d_[0-9][0-9][0-9][0-9]_count It's a little lengthy, but it works. Any better examples where we might want the exclude option? Huidae On Wed, Nov 19, 2008 at 12:40:52PM +0100, Markus Neteler wrote: On Wed, Nov 19, 2008 at 11:12 AM, Hamish [EMAIL PROTECTED] wrote: Markus wrote: g.mlist type=rast patt=gpcp_1dd_p1d_*_count exclude=month gpcp_1dd_p1d_1997_count gpcp_1dd_p1d_1998_count gpcp_1dd_p1d_1999_count gpcp_1dd_p1d_2000_count gpcp_1dd_p1d_2001_count gpcp_1dd_p1d_2002_count gpcp_1dd_p1d_2003_count gpcp_1dd_p1d_2004_count gpcp_1dd_p1d_2005_count gpcp_1dd_p1d_2006_count gpcp_1dd_p1d_2007_count I know that -r and -e are available but I failed to write an exclusion regex. And often just simple patterns are to be suppressed in the selection. no idea about the C version, but with the shell script version it would be roughly like if [ -n $GIS_OPT_EXCLUDE ] ; then EXCLD_STR=| grep -v $GIS_OPT_EXCLUDE else EXCLD_STR= fi g.list * ... | ... $EXCLD_STR Yes - but I dunno how to implement that in C. do you now use g.mlist | grep -v 'expr' ? g.mlist type=rast patt=gpcp_1dd_p1d_*_count | grep -v month | tr '\n' ',' | sed 's+,$++g but that's rather funky for daily usage. [for today, Paul's trick helped but the problem will return] Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
