> Hamish <[EMAIL PROTECTED]> writes:
[...]
>> In this locale g.mlist is broken. Eg. the command:
>> g.mlist rast pat=* sep=,
>> prints the following:
[...]
>> It looks that the Polish translation "raster plików dostêpnych w
>> mapsecie :", used in g.list, gets mixed into g.mlist
>>
Hamish pisze:
Maciej Sieczka wrote:
What's wrong?
The g.mlist script relies on the g.list module being run untranslated
Ah right.
The immediate fix is to add a couple of lines to the start of the script
temporarily disabling the locale settings, much like is done for scripts
that use aw
> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>>> To have concurrent access working properly, we would need to add
>>> explicit locking to all modules. Actually, we might be able to do
>>> it in g.parser, at least for modules whose options contain complete
>>> information (i.e. not m
> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>> It seems that you've missed my point. I wish to process the whole
>> raster with G_get_raster_row () once, and then another time from the
>> start. The only way to do it that I know is to close and re-open
>> it, which is ``a differe
> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>>> 2. Even when portable formats are used, the precise choice of
>>> format may be platform-specific.
>>> E.g. the row indices in the raster files can be 4 or 8 bytes,
>>> depending up the size of off_t in the code which creates them. T
By going through the r.cva options I finally figured
out the key to doing 'sites' analysis without
triggering a segfault: use the -i flag. This flag
seems to tell r.cva to ignore fields in the vector map
that may define the parameters spot, offseta, offsetb,
azimuth1, azimuth2, vert1, vert2, radius
Hamish wrote:
> > > Is there some fundamental reason why r.univar has separate cases for
> > > CELL/FCELL/DCELL types, rather than just working in DCELL throughout?
> >
> > On 2008-02-21 Hamish wrote:
> > I can't remember with any certainty why I did it that way; it's been
> > like that since the
Hamish wrote:
> > To make concurrent access work, updating a map would need to be an
> > atomic operation, so that any module which reads the map sees either
> > the "before" version or the "after" version, and never sees an
> > "in-progress" version.
> >
> > This means that while any module is
#100: v.surf.rst crashes on Mac OS X
---+
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: blocker | Milestone: 6.3.0
> Glynn Clements wrote:
> > Is there some fundamental reason why r.univar has separate cases for
> > CELL/FCELL/DCELL types, rather than just working in DCELL throughout?
>
> On 2008-02-21 Hamish wrote:
> I can't remember with any certainty why I did it that way; it's been
> like that since the fir
Glynn:
> To make concurrent access work, updating a map would need to be an
> atomic operation, so that any module which reads the map sees either
> the "before" version or the "after" version, and never sees an
> "in-progress" version.
>
> This means that while any module is in the process of ope
Ivan Shmakov wrote:
> > Any process which has the raster open for reading will be unaffected
> > by all of this, so long as it keeps the raster open (if it closes and
> > re-opens it, that's a different issue).
>
> It seems that you've missed my point. I wish to process the
> who
Maciej Sieczka wrote:
> My locale is:
>
> $ locale
> LANG=pl_PL.UTF-8
> LC_CTYPE="pl_PL.UTF-8"
> LC_NUMERIC="pl_PL.UTF-8"
> LC_TIME="pl_PL.UTF-8"
> LC_COLLATE="pl_PL.UTF-8"
> LC_MONETARY="pl_PL.UTF-8"
> LC_MESSAGES="pl_PL.UTF-8"
> LC_PAPER="pl_PL.UTF-8"
> LC_NAME="pl_PL.UTF-8"
> LC_ADDRESS="pl_
Maciej Sieczka wrote:
> $ locale
> LANG=pl_PL.UTF-8
> LC_CTYPE="pl_PL.UTF-8"
> LC_NUMERIC="pl_PL.UTF-8"
> LC_TIME="pl_PL.UTF-8"
> LC_COLLATE="pl_PL.UTF-8"
> LC_MONETARY="pl_PL.UTF-8"
> LC_MESSAGES="pl_PL.UTF-8"
> LC_PAPER="pl_PL.UTF-8"
> LC_NAME="pl_PL.UTF-8"
> LC_ADDRESS="pl_PL.UTF-8"
> LC_TELEP
Ivan Shmakov wrote:
> > 1. Individual modules can write whatever they want under cell_misc.
> > E.g. the fftreal and fftimag files written by i.fft are in host byte
> > order.
>
> Shouldn't these be fixed?
First, you need to identify which modules are doing this sort of
thing.
As for
My locale is:
$ locale
LANG=pl_PL.UTF-8
LC_CTYPE="pl_PL.UTF-8"
LC_NUMERIC="pl_PL.UTF-8"
LC_TIME="pl_PL.UTF-8"
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY="pl_PL.UTF-8"
LC_MESSAGES="pl_PL.UTF-8"
LC_PAPER="pl_PL.UTF-8"
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREME
> Glynn Clements <[EMAIL PROTECTED]> writes:
>> BTW, is there a way to ``lock'' on a raster (or its data at least),
>> so that it could be opened (or rewound) multiple times and, e. g.,
>> `G_get_raster_row' would return the same data, even if the raster
>> was, e. g., renamed meanwhile?
Ivan Shmakov wrote:
> BTW, is there a way to ``lock'' on a raster (or its data at
> least), so that it could be opened (or rewound) multiple times
> and, e. g., `G_get_raster_row' would return the same data, even
> if the raster was, e. g., renamed meanwhile?
That's alrea
> Glynn Clements <[EMAIL PROTECTED]> writes:
[...]
>>> GRASS_BATCH_JOB is a bit of a hack. You would be better off
>>> bypassing Init.sh altogether.
>> I wonder, is there a way to create locations non-interactively?
> g.proj -c location=...
ACK, thanks.
>> Or, does GRASS use
Being resent as this didn't make it to the list last night. It
answers some questions posed, but bottom line, WK's latest grass.sh -
sent directly to me - for OSX provides for my needs. At this time,
at least.
Joe
Begin forwarded message:
From: Joe Ostrowski <[EMAIL PROTECTED]>
Date: A
On 4/6/08 9:00 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Message: 2
> Date: Sun, 06 Apr 2008 13:59:05 +0700
> From: Ivan Shmakov <[EMAIL PROTECTED]>
> Subject: [GRASS-dev] creating location from the command line
> To: grass-dev@lists.osgeo.org
> Cc: Ivan Shmakov <[EMAIL PROTECTED]>
>
On Apr 6, 2008, at 10:55 AM, Glynn Clements wrote:
1. Individual modules can write whatever they want under cell_misc.
E.g. the fftreal and fftimag files written by i.fft are in host byte
order.
Ugh, didn't know about that one (we took care of the stroke fonts and
portable.h already). This w
BTW, is there a way to ``lock'' on a raster (or its data at
least), so that it could be opened (or rewound) multiple times
and, e. g., `G_get_raster_row' would return the same data, even
if the raster was, e. g., renamed meanwhile?
It seems to me that the co
Ivan Shmakov wrote:
> >> I tinkered with the grass.sh script in
> >> /Apps.../Grass-6.3.app/Contents/MacOS to bypass any of the GUI setup
> >> (X and Terminal windows) when GRASS_BATCH_JOB is non-empty. That
> >> provided the behavior I was after and didn't interfere with
> >> interactive u
#113: wxgrass: should automatically open display if layer added with no open
display
--+-
Reporter: mlennert | Owner: martinl
Type: enhancement | Status: closed
Prior
> Ivan Shmakov <[EMAIL PROTECTED]> writes:
> Maciej Sieczka <[EMAIL PROTECTED]> writes:
>> Talking about g.region vect= - I'd find it very usefull if it
>> honored the 3d vector coordinates too. Currently one has to set top
>> and bottom manually in accordance with his 3d vector.
> Do
26 matches
Mail list logo
