[GRASS-windows] r.sim.water
|
|
Helena Mitasova
|
Markus,
thanks for testing - I think simwe has a problem on MSwindows due to the problem with sites to vector update - that is why Glynn has disabled it. I need to comment out the site related stuff and it should run (I have the comments from Glynn, I just did not have time to get to it). I need to get it running on windows for my class, so I am going to get to it right away. Stefan - you can try r.hydro.casc2d, it was recently updated and it is in add-ons, it may soon get back into the main GRASS so it would be nice if somebody could run it, Helena On Fri, 2008-09-12 at 12:00 -0400, [hidden email] wrote: > Send grass-windows mailing list submissions to > [hidden email] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/grass-windows > or, via email, send a message with subject or body 'help' to > [hidden email] > > You can reach the person managing the list at > [hidden email] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of grass-windows digest..." > > > Today's Topics: > > 1. Re: r.sim.water (Stefan Frerichs) > 2. Re: r.sim.water (Markus Neteler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 12 Sep 2008 10:59:33 +0200 > From: Stefan Frerichs <[hidden email]> > Subject: Re: [GRASS-windows] r.sim.water > To: [hidden email] > Message-ID: <[hidden email]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Markus, > > I have imported a elevation IMG to Grass and get the following DEM: > > +----------------------------------------------------------------------------+ > | Layer: dgm@mapset Date: Wed Sep 10 11:35:01 2008 | > | Mapset: Mapset Login of Creator: stefan | > | Location: Location | > | DataBase: Path/DLM-D | > | Title: ( dgm ) | > | Timestamp: none | > |--------------------------------------------------------------------| > > | Type of Map: raster Number of Categories: 255 | > | Data Type: FCELL | > | Rows: 964 | > | Columns: 1202 | > | Total Cells: 1158728 | > | Projection: Transverse Mercator | > | N: 5652051.21010544 S: 5627951.21010544 Res: 25 | > | E: 2540019.37538876 W: 2509969.37538876 Res: 25 | > | Range of data: min = -263.843994 max = 299.535004 | > | | > | Data Description: | > | generated by r.in.gdal | > | | > | Comments: | > | r.in.gdal -o input="Path\dgm.img" output="dgm" | > | | > +----------------------------------------------------------------------------+ > > > >From here I set the region-settings to the DEM (as seen in my post to > your further inquiry) and build up dgm_dx and dgm_dy with r.slope.aspect: > > r.slope.aspect elevation=dgm@mapset format=degrees prec=float dx=dgm_dx > dy=dgm_dy zfactor=1.0 min_slp_allowed=0.0 > > Into the region I build a fractal map as model for a heavy rainfall (as > described in my first inquires) with this result: > > +----------------------------------------------------------------------------+ > | Layer: rainfall_d50@mapset Date: Thu Sep 11 10:10:37 2008 | > | Mapset: mapset Login of Creator: stefan | > | Location: location | > | DataBase: Path/DLM-D | > | Title: ( rainfall_d50 ) | > | Timestamp: none | > |----------------------------------------------------------------------------| > | | > | Type of Map: raster Number of Categories: 255 | > | Data Type: DCELL | > | Rows: 964 | > | Columns: 1202 | > | Total Cells: 1158728 | > | Projection: Transverse Mercator | > | N: 5652051.21010544 S: 5627951.21010544 Res: 25 | > | E: 2540019.37538876 W: 2509969.37538876 Res: 25 | > | Range of data: min = 2.787233 max = 83.784941 | > | | > | Data Description: | > | generated by r.mapcalc | > | | > | Comments: | > | surf_fractal_max300@mapset / 179.030000 * 50 | > | | > +----------------------------------------------------------------------------+ > > With this input I try to calculate the overland flow with r.sim.water > > r.sim.water -t elevin=dgm@mapset dxin=dgm_dx@mapset dyin=dgm_dy@mapset > rain=rainfall_d50@mapset rain_val=50 infil_val=0.0 manin_val=0.1 > depth=rainfall_depth disch=rainfall_dish nwalk=0 niter=10 outiter=5 > density=200 diffc=0.8 hmax=0.3 halpha=4.0 hbeta=0.5 > > with the well-known result ("Fr diesen Befehl ist nicht gengend > Speicher verfgbar") and r.sim.water-crash. > > As a variant I doesn't use the fractalmap rainfall_d50@mapset, but then > r.sim.water crashes without a message. > > When you (Markus) like to repeat my tries I can send you a link to a > ftp-server where you can download my data at all are a specific map > alone (only to Markus at this point, sorry to the list). My only > assumption, why r.sim.water not functioned with my data is, that the > rasters are too large ... > > Thank you very much for the time, you spend so long with my problem > Stefan > > Markus Neteler schrieb: > > Hi Stefan, > > > > On Thu, Sep 11, 2008 at 11:01 AM, Stefan Frerichs <[hidden email]> wrote: > >> Hi Markus, > >> > >> g.region -p have following output: > >> > >> rojection: 99 (Transverse Mercator) > > > > ouch! > > > >> zone: 0 > >> datum: potsdam > >> ellipsoid: bessel > >> north: 5652051.21010544 > >> south: 5627951.21010544 > >> west: 2509969.37538876 > >> east: 2540019.37538876 > >> nsres: 25 > >> ewres: 25 > >> rows: 964 > >> cols: 1202 > >> cells: 1158728 > >> > >> ("rojection" sic!) > > > > (That's very strange, cannot trace any broken word like this in 6.3.) > > > >> The Map-Unit is meter, as the elevation-raster comes in Gau-Krger > > > > ok. While I have a GK location, could you send the instructions to > > repeat your example? Or package up the location with relevant > > maps only for a test? > > > > Markus > > > > > > > > -- > _____________________________________________________ > > BKR Aachen Kirberichshofer Weg 6 > Castro & Hinzen D-52066 Aachen > Stadtplaner, Umweltplaner Fon +49 241 47058-0 > Fax +49 241 47058-15 > Amtsgericht Essen PR 43 www.bkr-ac.de > _____________________________________________________ > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Sep 2008 16:59:52 +0200 > From: "Markus Neteler" <[hidden email]> > Subject: Re: [GRASS-windows] r.sim.water > To: "Stefan Frerichs" <[hidden email]> > Cc: [hidden email] > Message-ID: > <[hidden email]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Stefan, > > I have downloaded your location from the secret server and run > > r.sim.water -t elevin=dgm dxin=dgm_dx dyin=dgm_dy \ > rain=surf_fractal_d50 rain_val=50 infil_val=0.0 manin_val=0.1 \ > depth=dgm_depth disch=dgm_disch niter=10 outiter=5 diffc=0.8 \ > hmax=0.3 halpha=4.0 hbeta=0.5 > default nwalk=2317456, rwalk=2317456.000000 > > Min elevation = -263.84 m > Max elevation = 299.54 m > Mean Source Rate (rainf. excess or sediment) = 0.000013 m/s or kg/m2s > Mean flow velocity = 1.530536 m/s > Mean Mannings = 0.100375 > Number of iterations = 36 cells > Time step = 4.08 s > 11% ... 100% > > Resulting maps are created: > dgm_depth.0294 dgm_depth.0588 > dgm_disch.0294 dgm_disch.0588 > > During execution (Linux, GRASS 6.4.svn), I have low memory consumption: > Mem: 3096356k total, 1878772k used, 1217584k free, 190628k buffers > > r.sim.water uses 6.6% of the memory, so not really much. > > I don't see relevant changes in r.sim.water between 6.3.svn and 6.4.svn. > Possibly there is a Windows related memory issue? > > Please submit a bug report: > http://grass.osgeo.org/grass63/binary/mswindows/native/#How%20to%20Submit%20Bugs > > I am not sure how to debug under Windows (here MingW). Maybe someone > here could give you hints > > In near future, we'll prepare a 6.4.0 release branch, hopefully a new Windows > version will be prepared then. > > Sorry for being no more help right now, under Linux it works. > > Markus > > > On Fri, Sep 12, 2008 at 10:59 AM, Stefan Frerichs <[hidden email]> wrote: > > Hi Markus, > > > > I have imported a elevation IMG to Grass and get the following DEM: > > > > +----------------------------------------------------------------------------+ > > | Layer: dgm@mapset Date: Wed Sep 10 11:35:01 2008 | > > | Mapset: Mapset Login of Creator: stefan | > > | Location: Location | > > | DataBase: Path/DLM-D | > > | Title: ( dgm ) | > > | Timestamp: none | > > |--------------------------------------------------------------------| > > > > | Type of Map: raster Number of Categories: 255 | > > | Data Type: FCELL | > > | Rows: 964 | > > | Columns: 1202 | > > | Total Cells: 1158728 | > > | Projection: Transverse Mercator | > > | N: 5652051.21010544 S: 5627951.21010544 Res: 25 | > > | E: 2540019.37538876 W: 2509969.37538876 Res: 25 | > > | Range of data: min = -263.843994 max = 299.535004 | > > | | > > | Data Description: | > > | generated by r.in.gdal | > > | | > > | Comments: | > > | r.in.gdal -o input="Path\dgm.img" output="dgm" | > > | | > > +----------------------------------------------------------------------------+ > > > > > > >From here I set the region-settings to the DEM (as seen in my post to > > your further inquiry) and build up dgm_dx and dgm_dy with r.slope.aspect: > > > > r.slope.aspect elevation=dgm@mapset format=degrees prec=float dx=dgm_dx > > dy=dgm_dy zfactor=1.0 min_slp_allowed=0.0 > > > > Into the region I build a fractal map as model for a heavy rainfall (as > > described in my first inquires) with this result: > > > > +----------------------------------------------------------------------------+ > > | Layer: rainfall_d50@mapset Date: Thu Sep 11 10:10:37 2008 | > > | Mapset: mapset Login of Creator: stefan | > > | Location: location | > > | DataBase: Path/DLM-D | > > | Title: ( rainfall_d50 ) | > > | Timestamp: none | > > |----------------------------------------------------------------------------| > > | | > > | Type of Map: raster Number of Categories: 255 | > > | Data Type: DCELL | > > | Rows: 964 | > > | Columns: 1202 | > > | Total Cells: 1158728 | > > | Projection: Transverse Mercator | > > | N: 5652051.21010544 S: 5627951.21010544 Res: 25 | > > | E: 2540019.37538876 W: 2509969.37538876 Res: 25 | > > | Range of data: min = 2.787233 max = 83.784941 | > > | | > > | Data Description: | > > | generated by r.mapcalc | > > | | > > | Comments: | > > | surf_fractal_max300@mapset / 179.030000 * 50 | > > | | > > +----------------------------------------------------------------------------+ > > > > With this input I try to calculate the overland flow with r.sim.water > > > > r.sim.water -t elevin=dgm@mapset dxin=dgm_dx@mapset dyin=dgm_dy@mapset > > rain=rainfall_d50@mapset rain_val=50 infil_val=0.0 manin_val=0.1 > > depth=rainfall_depth disch=rainfall_dish nwalk=0 niter=10 outiter=5 > > density=200 diffc=0.8 hmax=0.3 halpha=4.0 hbeta=0.5 > > > > with the well-known result ("Fr diesen Befehl ist nicht gengend > > Speicher verfgbar") and r.sim.water-crash. > > > > As a variant I doesn't use the fractalmap rainfall_d50@mapset, but then > > r.sim.water crashes without a message. > > > > When you (Markus) like to repeat my tries I can send you a link to a > > ftp-server where you can download my data at all are a specific map > > alone (only to Markus at this point, sorry to the list). My only > > assumption, why r.sim.water not functioned with my data is, that the > > rasters are too large ... > > > > Thank you very much for the time, you spend so long with my problem > > Stefan > > > > Markus Neteler schrieb: > >> Hi Stefan, > >> > >> On Thu, Sep 11, 2008 at 11:01 AM, Stefan Frerichs <[hidden email]> wrote: > >>> Hi Markus, > >>> > >>> g.region -p have following output: > >>> > >>> rojection: 99 (Transverse Mercator) > >> > >> ouch! > >> > >>> zone: 0 > >>> datum: potsdam > >>> ellipsoid: bessel > >>> north: 5652051.21010544 > >>> south: 5627951.21010544 > >>> west: 2509969.37538876 > >>> east: 2540019.37538876 > >>> nsres: 25 > >>> ewres: 25 > >>> rows: 964 > >>> cols: 1202 > >>> cells: 1158728 > >>> > >>> ("rojection" sic!) > >> > >> (That's very strange, cannot trace any broken word like this in 6.3.) > >> > >>> The Map-Unit is meter, as the elevation-raster comes in Gau-Krger > >> > >> ok. While I have a GK location, could you send the instructions to > >> repeat your example? Or package up the location with relevant > >> maps only for a test? > >> > >> Markus > >> > >> > >> > > > > -- > > _____________________________________________________ > > > > BKR Aachen Kirberichshofer Weg 6 > > Castro & Hinzen D-52066 Aachen > > Stadtplaner, Umweltplaner Fon +49 241 47058-0 > > Fax +49 241 47058-15 > > Amtsgericht Essen PR 43 www.bkr-ac.de > > _____________________________________________________ > > _______________________________________________ > > grass-windows mailing list > > [hidden email] > > http://lists.osgeo.org/mailman/listinfo/grass-windows > > > > > _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
Markus Neteler
|
Helena,
On Fri, Sep 12, 2008 at 6:19 PM, Helena Mitasova <[hidden email]> wrote: > Markus, > > thanks for testing - I think simwe has a problem on MSwindows due to > the problem with sites to vector update - that is why Glynn has disabled > it. when was it disabled (don't remember)? Post-6.3.? > I need to comment out the site related stuff and it should run > (I have the comments from Glynn, I just did not have time to get to it). > I need to get it running on windows for my class, so I am going to get > to it right away. > > Stefan - you can try r.hydro.casc2d, it was recently updated and it is > in add-ons, it may soon get back into the main GRASS so it would be nice > if somebody could run it, the trick is that it needs to be compiled on Windows with MingW... Markus _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Helena Mitasova
|
On Fri, 2008-09-12 at 18:52 +0200, Markus Neteler wrote: > Helena, > > On Fri, Sep 12, 2008 at 6:19 PM, Helena Mitasova <[hidden email]> wrote: > > Markus, > > > > thanks for testing - I think simwe has a problem on MSwindows due to > > the problem with sites to vector update - that is why Glynn has disabled > > it. > > when was it disabled (don't remember)? Post-6.3.? in trunk, I think it may still be in GRASS6.4 - I will check. I just ran it and I can confirm that it crashes on MS windows - we are running Marco's GRASS63 binary. In runs on GRASS63 linux version (compiled from source) and on older GRASS63 on Mac. Helena > > > I need to comment out the site related stuff and it should run > > (I have the comments from Glynn, I just did not have time to get to it). > > I need to get it running on windows for my class, so I am going to get > > to it right away. > > > > Stefan - you can try r.hydro.casc2d, it was recently updated and it is > > in add-ons, it may soon get back into the main GRASS so it would be nice > > if somebody could run it, > > the trick is that it needs to be compiled on Windows with MingW... > > Markus _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
Marco Pasetti-2
|
In reply to this post
by Markus Neteler
Hi all,
>> Stefan - you can try r.hydro.casc2d, it was recently updated and it is >> in add-ons, it may soon get back into the main GRASS so it would be nice >> if somebody could run it, > > the trick is that it needs to be compiled on Windows with MingW... I was going to reply on that. I would like to do the job for you, but I'm afraid, I'm very busy now. On late November I'll (should) start my PhD, so I'll have more time to do some GRASS works I already planned, including the addons builds and related installer. This said, you have two options: 1) wait for late November; 2) build the addon, following the instructions written into the "Develop your own GRASS modules on MS-Windows" document, available at http://trac.osgeo.org/grass/wiki/BuildingOnWindows (I'm updating it right now for the purpose). I'm really afraid to cannot give you much help, but that's all I can do for now :-( Regards, Marco _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
Glynn Clements
|
In reply to this post
by Markus Neteler
Markus Neteler wrote: > > thanks for testing - I think simwe has a problem on MSwindows due to > > the problem with sites to vector update - that is why Glynn has disabled > > it. > > when was it disabled (don't remember)? Post-6.3.? Only in 7.x. The compatibility wrappers use a "FILE *" in their interfaces, which is cast to/from a "struct Map_info *" internally. In 7.x, I changed this to use the correct type, and changed any code which uses those functions. Except that simwe has some mismatches, e.g. using G_sites_close() on a normal text file and using fclose() on a "pseudo-FILE*". With the changes to lib/sites, simwe doesn't compile, and I couldn't understand the code well enough to fix it, so I disabled it. [It doesn't help that there are various other problems with the code, e.g. each module having a private copy of waterglobs.h which doesn't necessarily match simlib.] The changes to lib/sites appear to have been back-ported to 6.4, but I don't know about the corresponding changes to the modules which use it. -- Glynn Clements <[hidden email]> _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Markus Neteler
|
On Sat, Sep 13, 2008 at 2:18 AM, Glynn Clements
<[hidden email]> wrote: > > Markus Neteler wrote: > >> > thanks for testing - I think simwe has a problem on MSwindows due to >> > the problem with sites to vector update - that is why Glynn has disabled >> > it. >> >> when was it disabled (don't remember)? Post-6.3.? > > Only in 7.x. > > The compatibility wrappers use a "FILE *" in their interfaces, which > is cast to/from a "struct Map_info *" internally. In 7.x, I changed > this to use the correct type, and changed any code which uses those > functions. This had been backported to 6.4.svn. > Except that simwe has some mismatches, e.g. using G_sites_close() on a > normal text file and using fclose() on a "pseudo-FILE*". With the > changes to lib/sites, simwe doesn't compile, and I couldn't understand > the code well enough to fix it, so I disabled it. I have now backported small fixes (essentially code order to do some computations post-parser instead of ante-parser. But that's not relevant. I have now compared simwe/ in 6.3.svn (after updating the code layout there to the new rules) to 6.4.svn. Besides above mentioned core-reorder, the only difference is: diff -ru --exclude=.svn /home/neteler/grass63_release/raster/simwe/simlib/output.c simwe/simlib/output.c --- /home/neteler/grass63_release/raster/simwe/simlib/output.c 2008-09-13 10:28:51.000000000 +0200 +++ simwe/simlib/output.c 2008-08-05 00:05:02.000000000 +0200 @@ -57,6 +57,8 @@ if (fdoutwalk == NULL) G_fatal_error("Cannot open %s", outwalk); else { + char buf[GNAME_MAX + 40]; + if (NULL == (sd = G_site_new_struct(-1, 2, 0, 1))) G_fatal_error("memory allocation failed for site"); @@ -65,9 +67,8 @@ else walkershead.name = outwalk; - walkershead.desc = G_strdup("output walkers"); - walkershead.desc = (char *)G_malloc(128 * sizeof(char)); - sprintf(walkershead.desc, "output walkers of %s [raster]", depth); + sprintf(buf, "output walkers of %s [raster]", depth); + walkershead.desc = G_store(buf); walkershead.time = NULL; walkershead.stime = NULL; walkershead.labels = NULL; Could this missing update in 6.3.svn cause a crash on Windows? A real candidate is the update to lib/sites/sites.c which isn't in GRASS 6.3.svn yet: --- /home/neteler/grass63_release/lib/sites/sites.c 2008-09-13 10:34:16.000000000 +0200 +++ ../lib/sites/sites.c 2008-08-05 00:05:18.000000000 +0200 @@ -50,16 +50,13 @@ * -2 on other fatal error or insufficient data, * 1 on format mismatch (extra data) */ -int G_site_get(FILE * fptr, Site * s) +int G_site_get(struct Map_info *Map, Site * s) { int i, type, cat; - struct Map_info *Map; static struct line_pnts *Points = NULL; static struct line_cats *Cats = NULL; SITE_ATT *sa; - Map = (struct Map_info *)fptr; - if (Points == NULL) Points = Vect_new_line_struct(); if (Cats == NULL) @@ -115,14 +112,11 @@ /* Writes a site to file open on fptr. */ -int G_site_put(FILE * fptr, const Site * s) +int G_site_put(struct Map_info *Map, const Site * s) { - struct Map_info *Map; static struct line_pnts *Points = NULL; static struct line_cats *Cats = NULL; - Map = (struct Map_info *)fptr; - if (Points == NULL) Points = Vect_new_line_struct(); if (Cats == NULL) @@ -156,12 +150,9 @@ * -1 on EOF, * -2 for other error. */ -int G_site_describe(FILE * ptr, int *dims, int *cat, int *strs, int *dbls) +int G_site_describe(struct Map_info *Map, int *dims, int *cat, int *strs, + int *dbls) { - struct Map_info *Map; - - Map = (struct Map_info *)ptr; - if (Vect_is_3d(Map)) { G_debug(1, "Vector is 3D -> number of site dimensions is 3"); *dims = 3; @@ -184,13 +175,10 @@ /*- * Writes site_head struct. */ -int G_site_put_head(FILE * ptr, Site_head * head) +int G_site_put_head(struct Map_info *Map, Site_head * head) { - struct Map_info *Map; static char buf[128]; - Map = (struct Map_info *)ptr; - if (head->name != NULL) Vect_set_map_name(Map, head->name); @@ -223,7 +211,8 @@ return -1; /* added to prevent crash 5/2000 MN */ } } - G_format_timestamp(head->time, head->stime); + G_format_timestamp(head->time, buf); + head->stime = G_store(buf); Vect_set_date(Map, head->stime); } } @@ -234,12 +223,8 @@ /*- * Fills in site_head struct. */ -int G_site_get_head(FILE * ptr, Site_head * head) +int G_site_get_head(struct Map_info *Map, Site_head * head) { - struct Map_info *Map; - - Map = (struct Map_info *)ptr; - head->name = Vect_get_name(Map); head->desc = Vect_get_comment(Map); head->form = NULL; @@ -293,11 +278,11 @@ * rejects all names that begin with . ********************************************************************** * - * FILE * + * struct Map_info * * G_sites_open_old (name, mapset) * opens the existing site list file 'name' in the 'mapset' * - * FILE * + * struct Map_info * * G_sites_open_new (name) * opens a new site list file 'name' in the current mapset * @@ -343,7 +328,7 @@ } -FILE *G_sites_open_old(char *name, char *mapset) +struct Map_info *G_sites_open_old(const char *name, const char *mapset) { struct Map_info *Map; struct field_info *fi; @@ -376,7 +361,7 @@ fi = Vect_get_field(Map, 1); if (fi == NULL) { /* not attribute table */ G_debug(1, "No attribute table"); - return (FILE *) Map; + return Map; } driver = db_start_driver_open_database(fi->driver, fi->database); @@ -476,11 +461,11 @@ qsort((void *)Map->site_att, Map->n_site_att, sizeof(SITE_ATT), site_att_cmp); - return (FILE *) Map; + return Map; } -FILE *G_sites_open_new(char *name) +struct Map_info *G_sites_open_new(const char *name) { struct Map_info *Map; @@ -494,16 +479,13 @@ G_debug(1, "New vector map opened"); - return (FILE *) Map; + return Map; } -void G_sites_close(FILE * ptr) +void G_sites_close(struct Map_info *Map) { int i, j; - struct Map_info *Map; - - Map = (struct Map_info *)ptr; if (Map->mode == GV_MODE_WRITE || Map->mode == GV_MODE_RW) Vect_build(Map, stderr); @@ -530,19 +512,19 @@ /* compatability while porting applications */ /*********************************************/ -FILE *G_fopen_sites_old(char *name, char *mapset) +struct Map_info *G_fopen_sites_old(const char *name, const char *mapset) { return G_sites_open_old(name, mapset); } -FILE *G_fopen_sites_new(char *name) +struct Map_info *G_fopen_sites_new(const char *name) { return G_sites_open_new(name); } -int G_get_site(FILE * fd, double *east, double *north, char **desc) +int G_get_site(struct Map_info *fd, double *east, double *north, char **desc) { /* TODO ? */ G_fatal_error("G_get_site() not yet updated."); @@ -551,7 +533,8 @@ } -int G_put_site(FILE * fd, double east, double north, const char *desc) +int G_put_site(struct Map_info *fd, double east, double north, + const char *desc) { /* TODO ? */ G_fatal_error("G_put_site() not yet updated."); @@ -1209,20 +1192,13 @@ Functions to obtain fields in order to draw sites with each point having a geometric property depending from database values. - - IN ALL THESE FUNCTIONS I FOLLOW THE CONVENTION TO PASS Map_info* as FILE* - FOR COHERENCE WITH OTHER ALREADY WRITTEN FUNCTION IN sites.c FILE. */ /* Returns a pointer to the SITE_ATT in Map_info *ptr and with category cat */ -SITE_ATT *G_sites_get_atts(FILE * ptr, int *cat) +SITE_ATT *G_sites_get_atts(struct Map_info * Map, int *cat) { - struct Map_info *Map; - - Map = (struct Map_info *)ptr; - return (SITE_ATT *) bsearch((void *)cat, (void *)Map->site_att, Map->n_site_att, sizeof(SITE_ATT), site_att_cmp); @@ -1233,13 +1209,13 @@ WARNING: user is responsible to free allocated memory, directly or calling G_sites_free_fields() */ -int G_sites_get_fields(FILE * ptr, char ***cnames, int **ctypes, int **ndx) +int G_sites_get_fields(struct Map_info *Map, char ***cnames, int **ctypes, + int **ndx) { - struct Map_info *Map; struct field_info *fi; int nrows, row, ncols, col, ndbl, nstr, ctype; - char *name; + const char *name; dbDriver *driver; dbString stmt; dbCursor cursor; @@ -1254,7 +1230,6 @@ Should it be not true in the future, maybe we'll have to change this by choosing appropriate fields and multiple categories */ - Map = (struct Map_info *)ptr; fi = (struct field_info *)Vect_get_field(Map, 1); On the other hand, fixing 6.3.svn is a waste of time since we'll branch of a release branch for 6.4.svn soon. Then release candidates will be created and hopefully a new WinGRASS package. > [It doesn't help that there are various other problems with the code, > e.g. each module having a private copy of waterglobs.h which doesn't > necessarily match simlib.] Markus _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Marco Pasetti-2
|
Hi all,
> On the other hand, fixing 6.3.svn is a waste of time since we'll > branch of a release branch for 6.4.svn soon. Then release > candidates will be created and hopefully a new WinGRASS package. I agree with that. One of the most importat item in my ToDo List is exactly to move my attention to the new developing branches (6.4 and 7). Hopefully very soon... Marco _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
Stefan Frerichs
|
In reply to this post
by Helena Mitasova
Hello Helena,
hi Markus, I have run r.sim.water successfully in a virtual Linux-box (the "GIS Virtual Machine" from www.gisvm.com with newly installed Grass 6.3 on VMWare Server). Maybe this a solution for a class, which have to run on windows? At least for a certain time? But I'm still waiting for a running version of r.sim.water for windows too ... Greeting Stefan Helena Mitasova schrieb: > Markus, > > thanks for testing - I think simwe has a problem on MSwindows due to > the problem with sites to vector update - that is why Glynn has disabled > it. I need to comment out the site related stuff and it should run > (I have the comments from Glynn, I just did not have time to get to it). > I need to get it running on windows for my class, so I am going to get > to it right away. > > Stefan - you can try r.hydro.casc2d, it was recently updated and it is > in add-ons, it may soon get back into the main GRASS so it would be nice > if somebody could run it, > > Helena grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Helena Mitasova
|
In reply to this post
by Markus Neteler
The fact that d.* commands are not available in winGRASS
has been discussed already but I am wondering what can be used to display or at least save images in very simple scripts (e.g. to automatize doing homework assignments) such as this http://skagit.meas.ncsu.edu/~helena/lteachtest/GIS_anal_grass/erosion.sh or the version without display is like this http://skagit.meas.ncsu.edu/~helena/lteachtest/GIS_anal_grass/ erosion_comp.sh We have started to use msys cli and simple scripts for some tasks and students really like it, especially for their projects but automated image output would be a great help. I am wondering whether I am missing something here, thank you, Helena P.S. "how can I get d.* or something similar running on winGRASS?" is usually the first and most persistent question I get, even from people who were informed that they should use GUI or who are used to ArcGIS _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Helena Mitasova
|
In reply to this post
by Markus Neteler
has anybody tried to run r.terraflow in winGRASS?
It cannot find or create the temp file? ami_single_temp_name: mkstemp failed : No such file or directory assertion failed: 0 file ami_stream.cc line 54 is it trying to write into /var/tmp which does not exist in windows? thanks, Helena On Sep 13, 2008, at 4:37 AM, Markus Neteler wrote: > On Sat, Sep 13, 2008 at 2:18 AM, Glynn Clements > <[hidden email]> wrote: >> >> Markus Neteler wrote: >> >>>> thanks for testing - I think simwe has a problem on MSwindows >>>> due to >>>> the problem with sites to vector update - that is why Glynn has >>>> disabled >>>> it. >>> >>> when was it disabled (don't remember)? Post-6.3.? >> >> Only in 7.x. >> >> The compatibility wrappers use a "FILE *" in their interfaces, which >> is cast to/from a "struct Map_info *" internally. In 7.x, I changed >> this to use the correct type, and changed any code which uses those >> functions. > > This had been backported to 6.4.svn. > >> Except that simwe has some mismatches, e.g. using G_sites_close() >> on a >> normal text file and using fclose() on a "pseudo-FILE*". With the >> changes to lib/sites, simwe doesn't compile, and I couldn't >> understand >> the code well enough to fix it, so I disabled it. > > I have now backported small fixes (essentially code order to do some > computations post-parser instead of ante-parser. But that's not > relevant. > > I have now compared simwe/ in 6.3.svn (after updating the code > layout there to the new rules) to 6.4.svn. Besides above mentioned > core-reorder, the only difference is: > > diff -ru --exclude=.svn > /home/neteler/grass63_release/raster/simwe/simlib/output.c > simwe/simlib/output.c > --- /home/neteler/grass63_release/raster/simwe/simlib/output.c > 2008-09-13 > 10:28:51.000000000 +0200 > +++ simwe/simlib/output.c 2008-08-05 00:05:02.000000000 +0200 > @@ -57,6 +57,8 @@ > if (fdoutwalk == NULL) > G_fatal_error("Cannot open %s", outwalk); > else { > + char buf[GNAME_MAX + 40]; > + > if (NULL == (sd = G_site_new_struct(-1, 2, 0, 1))) > G_fatal_error("memory allocation failed for site"); > > @@ -65,9 +67,8 @@ > else > walkershead.name = outwalk; > > - walkershead.desc = G_strdup("output walkers"); > - walkershead.desc = (char *)G_malloc(128 * sizeof(char)); > - sprintf(walkershead.desc, "output walkers of %s [raster]", > depth); > + sprintf(buf, "output walkers of %s [raster]", depth); > + walkershead.desc = G_store(buf); > walkershead.time = NULL; > walkershead.stime = NULL; > walkershead.labels = NULL; > > Could this missing update in 6.3.svn cause a crash on Windows? > > A real candidate is the update to lib/sites/sites.c which isn't in > GRASS 6.3.svn > yet: > > --- /home/neteler/grass63_release/lib/sites/sites.c 2008-09-13 > 10:34:16.000000000 +0200 > +++ ../lib/sites/sites.c 2008-08-05 00:05:18.000000000 +0200 > @@ -50,16 +50,13 @@ > * -2 on other fatal error or insufficient data, > * 1 on format mismatch (extra data) > */ > -int G_site_get(FILE * fptr, Site * s) > +int G_site_get(struct Map_info *Map, Site * s) > { > int i, type, cat; > - struct Map_info *Map; > static struct line_pnts *Points = NULL; > static struct line_cats *Cats = NULL; > SITE_ATT *sa; > > - Map = (struct Map_info *)fptr; > - > if (Points == NULL) > Points = Vect_new_line_struct(); > if (Cats == NULL) > @@ -115,14 +112,11 @@ > > > /* Writes a site to file open on fptr. */ > -int G_site_put(FILE * fptr, const Site * s) > +int G_site_put(struct Map_info *Map, const Site * s) > { > - struct Map_info *Map; > static struct line_pnts *Points = NULL; > static struct line_cats *Cats = NULL; > > - Map = (struct Map_info *)fptr; > - > if (Points == NULL) > Points = Vect_new_line_struct(); > if (Cats == NULL) > @@ -156,12 +150,9 @@ > * -1 on EOF, > * -2 for other error. > */ > -int G_site_describe(FILE * ptr, int *dims, int *cat, int *strs, > int *dbls) > +int G_site_describe(struct Map_info *Map, int *dims, int *cat, int > *strs, > + int *dbls) > { > - struct Map_info *Map; > - > - Map = (struct Map_info *)ptr; > - > if (Vect_is_3d(Map)) { > G_debug(1, "Vector is 3D -> number of site dimensions is 3"); > *dims = 3; > @@ -184,13 +175,10 @@ > /*- > * Writes site_head struct. > */ > -int G_site_put_head(FILE * ptr, Site_head * head) > +int G_site_put_head(struct Map_info *Map, Site_head * head) > { > - struct Map_info *Map; > static char buf[128]; > > - Map = (struct Map_info *)ptr; > - > if (head->name != NULL) > Vect_set_map_name(Map, head->name); > > @@ -223,7 +211,8 @@ > return -1; /* added to prevent crash 5/2000 MN */ > } > } > - G_format_timestamp(head->time, head->stime); > + G_format_timestamp(head->time, buf); > + head->stime = G_store(buf); > Vect_set_date(Map, head->stime); > } > } > @@ -234,12 +223,8 @@ > /*- > * Fills in site_head struct. > */ > -int G_site_get_head(FILE * ptr, Site_head * head) > +int G_site_get_head(struct Map_info *Map, Site_head * head) > { > - struct Map_info *Map; > - > - Map = (struct Map_info *)ptr; > - > head->name = Vect_get_name(Map); > head->desc = Vect_get_comment(Map); > head->form = NULL; > @@ -293,11 +278,11 @@ > * rejects all names that begin with . > > ********************************************************************** > * > - * FILE * > + * struct Map_info * > * G_sites_open_old (name, mapset) > * opens the existing site list file 'name' in the 'mapset' > * > - * FILE * > + * struct Map_info * > * G_sites_open_new (name) > * opens a new site list file 'name' in the current mapset > * > @@ -343,7 +328,7 @@ > } > > > -FILE *G_sites_open_old(char *name, char *mapset) > +struct Map_info *G_sites_open_old(const char *name, const char > *mapset) > { > struct Map_info *Map; > struct field_info *fi; > @@ -376,7 +361,7 @@ > fi = Vect_get_field(Map, 1); > if (fi == NULL) { /* not attribute table */ > G_debug(1, "No attribute table"); > - return (FILE *) Map; > + return Map; > } > > driver = db_start_driver_open_database(fi->driver, fi->database); > @@ -476,11 +461,11 @@ > qsort((void *)Map->site_att, Map->n_site_att, sizeof(SITE_ATT), > site_att_cmp); > > - return (FILE *) Map; > + return Map; > } > > > -FILE *G_sites_open_new(char *name) > +struct Map_info *G_sites_open_new(const char *name) > { > struct Map_info *Map; > > @@ -494,16 +479,13 @@ > > G_debug(1, "New vector map opened"); > > - return (FILE *) Map; > + return Map; > } > > > -void G_sites_close(FILE * ptr) > +void G_sites_close(struct Map_info *Map) > { > int i, j; > - struct Map_info *Map; > - > - Map = (struct Map_info *)ptr; > > if (Map->mode == GV_MODE_WRITE || Map->mode == GV_MODE_RW) > Vect_build(Map, stderr); > @@ -530,19 +512,19 @@ > /* compatability while porting applications */ > > /*********************************************/ > -FILE *G_fopen_sites_old(char *name, char *mapset) > +struct Map_info *G_fopen_sites_old(const char *name, const char > *mapset) > { > return G_sites_open_old(name, mapset); > } > > > -FILE *G_fopen_sites_new(char *name) > +struct Map_info *G_fopen_sites_new(const char *name) > { > return G_sites_open_new(name); > } > > > -int G_get_site(FILE * fd, double *east, double *north, char **desc) > +int G_get_site(struct Map_info *fd, double *east, double *north, > char **desc) > { > /* TODO ? */ > G_fatal_error("G_get_site() not yet updated."); > @@ -551,7 +533,8 @@ > } > > > -int G_put_site(FILE * fd, double east, double north, const char > *desc) > +int G_put_site(struct Map_info *fd, double east, double north, > + const char *desc) > { > /* TODO ? */ > G_fatal_error("G_put_site() not yet updated."); > @@ -1209,20 +1192,13 @@ > > Functions to obtain fields in order to draw sites with each > point having a > geometric property depending from database values. > - > - IN ALL THESE FUNCTIONS I FOLLOW THE CONVENTION TO PASS > Map_info* as FILE* > - FOR COHERENCE WITH OTHER ALREADY WRITTEN FUNCTION IN sites.c FILE. > */ > > /* > Returns a pointer to the SITE_ATT in Map_info *ptr and with > category cat > */ > -SITE_ATT *G_sites_get_atts(FILE * ptr, int *cat) > +SITE_ATT *G_sites_get_atts(struct Map_info * Map, int *cat) > { > - struct Map_info *Map; > - > - Map = (struct Map_info *)ptr; > - > return (SITE_ATT *) bsearch((void *)cat, (void *)Map->site_att, > Map->n_site_att, sizeof(SITE_ATT), > site_att_cmp); > @@ -1233,13 +1209,13 @@ > > WARNING: user is responsible to free allocated memory, directly or > calling G_sites_free_fields() > */ > -int G_sites_get_fields(FILE * ptr, char ***cnames, int **ctypes, > int **ndx) > +int G_sites_get_fields(struct Map_info *Map, char ***cnames, int > **ctypes, > + int **ndx) > { > - struct Map_info *Map; > struct field_info *fi; > int nrows, row, ncols, col, ndbl, nstr, ctype; > > - char *name; > + const char *name; > dbDriver *driver; > dbString stmt; > dbCursor cursor; > @@ -1254,7 +1230,6 @@ > Should it be not true in the future, maybe we'll have to > change this by choosing > appropriate fields and multiple categories */ > > - Map = (struct Map_info *)ptr; > fi = (struct field_info *)Vect_get_field(Map, 1); > > On the other hand, fixing 6.3.svn is a waste of time since we'll > branch of a release branch for 6.4.svn soon. Then release > candidates will be created and hopefully a new WinGRASS package. > >> [It doesn't help that there are various other problems with the code, >> e.g. each module having a private copy of waterglobs.h which doesn't >> necessarily match simlib.] > > Markus _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Glynn Clements
|
In reply to this post
by Helena Mitasova
Helena Mitasova wrote: > The fact that d.* commands are not available in winGRASS > has been discussed already The majority of d.* commands are available in WinGRASS; they just render directly to an image file rather than using a monitor. The main exception is that commands which rely upon the mouse won't work. Likewise for scripts which rely upon persistent state (e.g. d.frame). > but I am wondering what can > be used to display or at least save images in very simple scripts > (e.g. to automatize doing homework assignments) such as > this > > http://skagit.meas.ncsu.edu/~helena/lteachtest/GIS_anal_grass/erosion.sh AFAICT, that could be made to work with direct rendering without too much trouble. Set GRASS_PNGFILE instead of using d.out.file, and replace d.rast.leg with separate d.rast and d.legend commands (you can set GRASS_PNG_READ=TRUE to overlay output on an existing file rather than replacing it). > or the version without display is like this > http://skagit.meas.ncsu.edu/~helena/lteachtest/GIS_anal_grass/erosion_comp.sh > > We have started to use msys cli and simple scripts for some tasks > and students really like it, especially for their projects > but automated image output would be a great help. I am wondering whether > I am missing something here, Immediate rendering. If you're using the native Windows version, or using GRASS 7.x, or if GRASS_RENDER_IMMEDIATE=TRUE, all d.* commands generate (or modify) a graphics file instead of communicating with a separate monitor process. This is how gis.m and the wx GUI work. See the pngdriver (also psdriver, cairodriver) manpages for details of various environment variables which control the behaviour of d.* commands. -- Glynn Clements <[hidden email]> _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Marco Pasetti-2
|
In reply to this post
by Helena Mitasova
Hi Helena,
> has anybody tried to run r.terraflow in winGRASS? > > It cannot find or create the temp file? > ami_single_temp_name: mkstemp failed : No such file or directory > assertion failed: 0 file ami_stream.cc line 54 > is it trying to write into /var/tmp which does not exist in windows? > > thanks, > > Helena I never used r.terraflow. Please give me a command line example and I'll try to do that. unfortunately my "chief" here at university "took" my copy of the grassbook; but there are good news, anyway, because yesterday he told me that he added the grassbook to the "shopping cart" of the faculty; I hope this will be the first step to officially put GRASS into my PhD jobs here at university :) Regards, Marco _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Markus Neteler
|
In reply to this post
by Helena Mitasova
On Thu, Nov 6, 2008 at 6:18 AM, Helena Mitasova <[hidden email]> wrote:
> has anybody tried to run r.terraflow in winGRASS? > > It cannot find or create the temp file? > ami_single_temp_name: mkstemp failed : No such file or directory A random search shows http://osdir.com/ml/gnome.apps.pan.devel/2006-05/msg00007.html mkstemp impl for windows: msg#00007 gnome.apps.pan.devel > assertion failed: 0 file ami_stream.cc line 54 > is it trying to write into /var/tmp which does not exist in windows? Apparently a wrapper is needed (?). Markus _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
|
Glynn Clements
|
In reply to this post
by Helena Mitasova
Helena Mitasova wrote: > has anybody tried to run r.terraflow in winGRASS? > > It cannot find or create the temp file? > ami_single_temp_name: mkstemp failed : No such file or directory > assertion failed: 0 file ami_stream.cc line 54 > is it trying to write into /var/tmp which does not exist in windows? 1. The error message is inaccurate; it doesn't actually call mkstemp() on Windows, but mktemp(). 2. The directory used for temporary files is controlled by the STREAM_DIR= option (renamed to stream_dir= in 7.0). /var/tmp is just the default setting. 3. The default value of /var/tmp is inappropriate for Windows. It should probably use the TMP or TEMP environment variables. There probably won't be a specific directory which will be writable by all users. -- Glynn Clements <[hidden email]> _______________________________________________ grass-windows mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/grass-windows |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
