[GRASS-dev] NULL file compression: loop over uncompressed maps to save disk space

Markus Neteler neteler at osgeo.org
Wed Jan 11 07:53:18 PST 2017


On Wed, Jan 11, 2017 at 3:06 PM, Markus Metz
<markus.metz.giswork at gmail.com> wrote:
> On Wed, Jan 11, 2017 at 12:37 PM, Markus Neteler <neteler at osgeo.org> wrote:
>> On Wed, Jan 11, 2017 at 10:34 AM, Markus Metz
....
>> > Note that this is not standard shell style because the module accepts
>> > several input maps, thus compression info is written to stdout as one
>> > line per input map. The format is
>> > input map name|data type|name of data compression method|NULL file
>> > compression
>> > e.g.
>> > eu_dem25|FCELL|ZLIB|NO
>> > or
>> > eu_dem25|FCELL|BZIP2|YES
>>
>> Yes, that's quite useful like this. Maybe a small modification to make
>> it usable for the beloved eval() function?
>>
>> r.compress -g eu_dem25
>> eu_dem25=FCELL|ZLIB|YES
>> ?
>
> In this case, eu_dem25 would be both the name of a raster map and the name
> of a variable, I find this confusing. And you still need to split the
> result. I guess parsing
> eu_dem25|FCELL|ZLIB|YES
> would be slightly easier in python than
> eu_dem25=FCELL|ZLIB|YES
>
>> This would keep the -g implementations consistent across different
>> commands.
>
> Full easy support for eval() is not possible if the same parameters are
> printed several times. See e.g. r.univar -gt with a zonal map, r.quantile,
> r.stats.quantile or v.db.connect -g with several connections defined.
> Therefore I would use one line with name=value where possible, otherwise one
> line per input with separated fields. I would not mix the two, IMHO it will
> cause confusion.

ok fine. After a bit of testing I suggest to backport the new flag and
r.null messages so that NULL compression becomes easy also in 7.2 (I
enjoyed already the --exec interface to loop over all mapsets from
outside and compress all maps therein).

markusN


More information about the grass-dev mailing list