#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.
#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.
#172: r.recode truncates last character in rules file.
---+
Reporter: bgullatt | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone:
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 div
#105: r.in.xyz: zscale parameter addition patch
--+-
Reporter: neteler | Owner: hamish
Type: enhancement | Status: reopened
Priority: major| Milestone: 6.4.0
Component: defau
#105: r.in.xyz: zscale parameter addition patch
--+-
Reporter: neteler | Owner: hamish
Type: enhancement | Status: closed
Priority: major| Milestone: 6.4.0
Component: defau
#105: r.in.xyz: zscale parameter addition patch
--+-
Reporter: neteler | Owner: hamish
Type: enhancement | Status: assigned
Priority: major| Milestone: 6.4.0
Component: defau
#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
#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
#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
#120: New v.example proposal
--+-
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone: 6.4.0
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.
#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.
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 me
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_hi
#180: Sqlite driver doesn't handle blank numeric entries
---+
Reporter: ferrouswheel | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major
16 matches
Mail list logo
