Re: [GRASS-dev] storing full script as metadata
Yann Chemin wrote: Just wanted to keep exact track of the processing leading to a new layer. 1 - would it be feasible to store the whole processing line with parameters (i.e. r.something -a input=file_in output-file_out etc...) as metadata in the output file of a module ? G_command_history() already does this, i.e. it appends the result of G_recreate_command() to the history. 2 - would it be interesting to make a scripts/ place inside a mapset where scripts would get automatically saved with something like: MMMDDH_MODULE_NAME.sh or the like? I'm not sure what you're suggesting here. GRASS (the libraries and modules) only knows which commands are run; it doesn't know *how* they are run, e.g. if they are part a script, if they were typed into the shell, executed by the GUI, etc. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] storing full script as metadata
2008/6/9 Glynn Clements [EMAIL PROTECTED]: Yann Chemin wrote: Just wanted to keep exact track of the processing leading to a new layer. 1 - would it be feasible to store the whole processing line with parameters (i.e. r.something -a input=file_in output-file_out etc...) as metadata in the output file of a module ? G_command_history() already does this, i.e. it appends the result of G_recreate_command() to the history. G_recreate_command() OK I'll look into it. 2 - would it be interesting to make a scripts/ place inside a mapset where scripts would get automatically saved with something like: MMMDDH_MODULE_NAME.sh or the like? I'm not sure what you're suggesting here. GRASS (the libraries and modules) only knows which commands are run; it doesn't know *how* they are run, e.g. if they are part a script, if they were typed into the shell, executed by the GUI, etc. well, since G_recreate_command passed it into the metadata, I guess already that is good. I was thinking more of a kind of command log, but with time-based separation of commands used in txt files. Whether they are stored inside a mapset would just be convenient. thanks Yann -- Glynn Clements [EMAIL PROTECTED] -- Yann Chemin International Rice Research Institute Office: http://www.irri.org/gis Perso: http://www.freewebs.com/ychemin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] storing full script as metadata
Yann Chemin wrote: well, since G_recreate_command passed it into the metadata, I guess already that is good. I was thinking more of a kind of command log, but with time-based separation of commands used in txt files. Whether they are stored inside a mapset would just be convenient. see also 'v.info -h mapname' for some developed mapname which is the result of a number of vector module processing steps. and the raster-metadata rewrite task suggestion box on the grass wiki grass7 ideas page. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #184: v.in.garmin - detect gpstrans or gardump instead of user flag
#184: v.in.garmin - detect gpstrans or gardump instead of user flag --+- Reporter: kyngchaos| Owner: hamish Type: enhancement | Status: assigned Priority: minor| Milestone: 6.4.0 Component: default | Version: 6.3.0 Resolution: |Keywords: v.in.garmin --+- Changes (by hamish): * status: new = assigned * owner: grass-dev@lists.osgeo.org = hamish * cc: grass-dev@lists.osgeo.org (added) Comment: On reflection I think the flag is better. Of course we can improve the error message to suggest using the flag if the download program isn't found. The two programs (and gpsbabel too for that matter) are not direct equivalents. Each one has its own strengths WRT attribute handling on different garmin models (usually WRT waypoint metadata fields). I have both gardump and gpstrans installed, so hardcoding the script to run the first one it finds removes my ability to choose. Adding some sort of environment variable to override that hardcoding is a regression from the current situation IMO. I don't consider it such a bad thing that the user know what 3rd party programs they have installed and are running. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/184#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] Re: [GRASS GIS] #120: New v.example proposal
#120: New v.example proposal --+- Reporter: marisn | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: Docs | Version: svn-trunk Resolution: |Keywords: example --+- Comment (by neteler): Hi Maris, I have tried and the patch works. Please submit to SVN... Markus -- Ticket URL: http://trac.osgeo.org/grass/ticket/120#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] #22: Grass r.out.mat 64bit Matlab reading problem
#22: Grass r.out.mat 64bit Matlab reading problem --+- Reporter: alexice | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: minor| Milestone: 6.3.0 Component: default | Version: 6.2.3 Resolution: fixed|Keywords: --+- Comment (by neteler): I have uploaded the exported Spearfish roads raster map, exported on 64bit Linux box (Mandriva 2008.0). Markus -- Ticket URL: http://trac.osgeo.org/grass/ticket/22#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] #22: Grass r.out.mat 64bit Matlab reading problem
#22: Grass r.out.mat 64bit Matlab reading problem --+- Reporter: alexice | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: minor| Milestone: 6.3.0 Component: default | Version: 6.2.3 Resolution: fixed|Keywords: r.out.mat endian --+- Changes (by hamish): * keywords: = r.out.mat endian Comment: Replying to [comment:11 neteler]: I have uploaded the exported Spearfish roads raster map, exported on 64bit Linux box (Mandriva 2008.0). I will test the file, but I think this is solved. Specifically the 64 bit error should be solved by: Glynn: For now, I've simply replaced long with int, as the latter will be 32 bits on nearly all systems. That should fix the 64-bit problems, but it won't do anything about byte order. and thus this bug (wrt 64bit) is closed. A remaining problem is to fix the endian stuff. or do you experience something else? Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/22#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] Re: [GRASS GIS] #105: r.in.xyz: zscale parameter addition patch
#105: r.in.xyz: zscale parameter addition patch --+- Reporter: neteler | Owner: hamish Type: enhancement | Status: assigned Priority: major| Milestone: 6.4.0 Component: default | Version: svn-trunk Resolution: |Keywords: r.in.xyz --+- Changes (by hamish): * keywords: = r.in.xyz Comment: Patch committed by Markus; looks good. Closing wish. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/105#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] Re: [GRASS GIS] #105: r.in.xyz: zscale parameter addition patch
#105: r.in.xyz: zscale parameter addition patch --+- Reporter: neteler | Owner: hamish Type: enhancement | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: svn-trunk Resolution: fixed|Keywords: r.in.xyz --+- Changes (by hamish): * status: assigned = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/105#comment:5 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] #105: r.in.xyz: zscale parameter addition patch
#105: r.in.xyz: zscale parameter addition patch
--+-
Reporter: neteler | Owner: hamish
Type: enhancement | Status: reopened
Priority: major| Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: |Keywords: r.in.xyz
--+-
Changes (by hamish):
* status: closed = reopened
* resolution: fixed =
Comment:
{{{
z=z/zscale;
}}}
shouldn't that be {{{z *= zscale;}}} ??
Hamish
--
Ticket URL: http://trac.osgeo.org/grass/ticket/105#comment:6
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] GRASS 7 development started
On Fri, May 30, 2008 at 10:30 PM, Glynn Clements [EMAIL PROTECTED] wrote: Hamish wrote: Any final comments before the entire source tree is reformatted? Any thoughts on keeping the inter-branch svn merge effort low? Don't merge? Eventually, 7.x and 6.x are going to diverge by more than just formatting. As suggested earlier: we re-indent both and the problem is solved (agreed that 7.x and 6.x are going to diverge way more in the future). ... Anyone who wanted to comment on the formatting should probably have done so in the month since this thread was started. Right. Question: why don't we go ahead and just do it? Procedure: Server-side: - announce date/time of indent code reformatting - publish the final parameter set - run on 7.x.trunk, submit - run on 6.4.branch, submit You local SVN copy: - DONT UPDATE YET but run svn status - files with local uncommitted changes (M) need to be treated with the indent command on the *unsubmitted* changed files to avoid later update conflicts - *then* update from SVN to re-sync with svn update Makes sense? Can we go ahead? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #172: r.recode truncates last character in rules file.
#172: r.recode truncates last character in rules file. ---+ Reporter: bgullatt | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.3.1 Component: default | Version: 6.3.0 Resolution:|Keywords: r.recode rules ---+ Comment (by neteler): Any objections that I apply this patch? Markus -- Ticket URL: http://trac.osgeo.org/grass/ticket/172#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] Re: [GRASS GIS] #91: ps.map doesn't remove .tmp files when it is done
#91: ps.map doesn't remove .tmp files when it is done --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: --+- Comment (by neteler): Any objections that I apply attached patch? Markus -- Ticket URL: http://trac.osgeo.org/grass/ticket/91#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
