r.info|v.info|r3.info|t.info: display map size used on disk

[neteler]

At time it is difficult to estimate the disk usage of map in GRASS GIS. Especially, because one map consists of several files.

An additional entry in the output of r.info|v.info|r3.info|t.info would be very useful (use case: think about estimation of storage consumption and billing in a cloud environment).

[neteler]

Here some code which could probably support the implementation:

• ​https://github.com/OSGeo/grass-addons/blob/master/grass7/general/g.compare.md5/g.compare.md5.py

For SQLite table sizes (apparently not easy to obtain):

• ​https://stackoverflow.com/questions/27572387/query-that-returns-the-size-of-a-table-in-a-sqlite-database#36627097

Hence (​https://www.sqlite.org/dbstat.html):

sqlite3 nc_spm_08_grass7/PERMANENT/sqlite/sqlite.db

# page size
sqlite> SELECT SUM("pgsize") FROM "dbstat" WHERE name='zipcodes_wake';
5120
sqlite> SELECT SUM("pgsize") FROM "dbstat" WHERE name='roadsmajor';
12288

[mmetz]

Regarding raster maps, a better place to report disk usage would be r.compress, because with r.compress you could test which compression method is most appropriate for your use case (trade-off between disk usage and IO speed).

[neteler]

Well, agreed: r.compress might be another good place.

At time I need to check already existing maps (time series and tiles of mosaics), so r.info seems to be most appropriate.

[mmetz]

Thinking about it, r.info seems more appropriate.

In any case you should really use r.compress with different compression methods to decide on the compression method appropriate for your needs. r.compress also reports changes in disk usage when re-compressing.

Another easy way to estimate disk usage is the file size of the output of [r|v].pack -c.

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after milestone closed