Hi,
2015-06-11 16:59 GMT+02:00 Vaclav Petras :
> Anyway, my point is that parallel calls to r.to.vect are terribly slow with
> default configuration and one must know that the solution is to change the
> attribute table backend to Postgres (or perhaps DBF where there is one
> database file per vec
On Thu, Jun 11, 2015 at 10:11 AM, Glynn Clements
wrote:
>
> > Anyway, I think that non-atomicity during copy (instead of move) when
> > requested (by GRASS_TMPDIR_MAPSET) is not much worse than anything else
> > what one must deal with when using GRASS on some advanced configuration.
> > For examp
Vaclav Petras wrote:
> > I am not sure why it must be so on (if files are not on the same
> > filesystem, they can be copied), anyway I changed it in r65436.
> > GRASS_TMPDIR_MAPSET is accepted only by vector library. Martin
>
> I don't understand why it should be OK for vectors when it is not O
Martin Landa wrote:
> > There is no justification for the current behaviour. The temporary
> > cell/fcell and null files should always be created in the mapset's
> > temporary directory.
>
> I am not sure why it must be so on (if files are not on the same
> filesystem, they can be copied),
A co
On Wed, Jun 10, 2015 at 3:05 PM, Martin Landa
wrote:
>
> 2015-06-10 17:41 GMT+02:00 Glynn Clements :
> >
> > Vaclav Petras wrote:
> >
> >> First, it allows unorthodox behavior of GRASS but this behavior is (or
at
> >> least should be) applied only when GRASS_TMPDIR_MAPSET is set to some
> >> speci
2015-06-10 21:05 GMT+02:00 Martin Landa :
[...]
> I am not sure why it must be so on (if files are not on the same
> filesystem, they can be copied), anyway I changed it in r65436.
> GRASS_TMPDIR_MAPSET is accepted only by vector library. Martin
the question is whether to rename this variable to
Hi,
2015-06-10 17:41 GMT+02:00 Glynn Clements :
>
> Vaclav Petras wrote:
>
>> First, it allows unorthodox behavior of GRASS but this behavior is (or at
>> least should be) applied only when GRASS_TMPDIR_MAPSET is set to some
>> specific value. I don't see much problem with it as long as the
>> doc
Vaclav Petras wrote:
> First, it allows unorthodox behavior of GRASS but this behavior is (or at
> least should be) applied only when GRASS_TMPDIR_MAPSET is set to some
> specific value. I don't see much problem with it as long as the
> documentation properly discuss all the potential issues and
Moving the conversation from the ticket.
On Sat, Jun 6, 2015 at 9:16 AM, GRASS GIS wrote:
>
> #2349: CELL raster format: make ZLIB level 3 standard compression instead
of RLE
> --+---
> Reporter: neteler | Owner: grass-
