Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE

2015-04-28 Thread GRASS GIS
#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  critical |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  compression, r.compress, null
   CPU:  Unspecified  |   Platform:  All
--+---

Comment (by neteler):

 Replying to [comment:16 glynn]:
  How large are the null files compared to the cell/fcell files?

  * With MODIS LST data, the null files are between 1.7 and 7.6 times
 larger than the cell files (we store the LST maps in deg C * 100 as
 integer to save disk space).
  * With 100k random points, the null file is 7.1 times larger than the
 fcell map
  * With the EU 25m DEM, the null file is way smaller that the derived
 aspect map (17% of the DEM fcell file)

   What about having a null2 file which is compressed and with index.
 If present, fine, otherwise use the uncompressed well known null file
 format?
 
  That's probably not a great deal of work, but as with any such change,
 we need to consider the migration strategy. If we just start creating
 compressed null files, mapsets will cease to be usable with older
 versions.

 Right but this could be covered with an addon/new script in G6 and earlier
 (as v.build does for vector data).

--
Ticket URL: https://trac.osgeo.org/grass/ticket/2349#comment:17
GRASS GIS http://grass.osgeo.org

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Limit in g.message? was: Limit in number of variables for r.mapcalc?

2015-04-28 Thread Glynn Clements

Markus Neteler wrote:

  But more significantly, G_message() etc use an internal buffer of 2000
  bytes. A message longer than that probably won't work and may well
  cause the g.message to crash.
 
 How about (ab)using GPATH_MAX (include/gis.h) which is 4096 chars long
 and using it in
 general/g.message/main.c as well to avoid a buffer overflow?

Having g.message limit the length of a message would work for
g.message.

For G_message() etc, using vsnprintf() would work, but that's C99.

G_vasprintf() should work, but our private implementation (used if
asprintf() doesn't exist) also requires C99.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE

2015-04-28 Thread GRASS GIS
#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  critical |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  compression, r.compress, null
   CPU:  Unspecified  |   Platform:  All
--+---

Comment (by glynn):

 Replying to [comment:15 neteler]:
  back to this topic: Here on our system I found  1.7TB of NULL files in
 a single location, all
  uncompressed.

 How large are the null files compared to the cell/fcell files?

  What about having a null2 file which is compressed and with index. If
 present, fine, otherwise use the uncompressed well known null file format?

 That's probably not a great deal of work, but as with any such change, we
 need to consider the migration strategy. If we just start creating
 compressed null files, mapsets will cease to be usable with older
 versions.

--
Ticket URL: https://trac.osgeo.org/grass/ticket/2349#comment:16
GRASS GIS http://grass.osgeo.org

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS

2015-04-28 Thread Matej Krejci
Hi,
Thanks for the chance to participate on GSOC 2015. The page about project
is on wiki site[1]. Thank you for ideas and notes in advance.

Matej

[1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

2015-03-11 1:55 GMT+01:00 Matej Krejci matejkre...@gmail.com:

 Hi all,

 Last GSOC I was working on ISO based metadata management for GRASS. In
 this term I was created 'package' wx.metadata which is currently available
 in GRASS add-ons. This part was essential. During playing with
 possibilities of implementation I did a draft of metadata catalogue which
 is the main task of current GSOC topic[1]. Moreover to implement additional
 functions (see list[1]) for current metadata modules is more than suitable.
 Since last GSOC I am still slightly in coding for GRASS and I like to
 continue in this topic. Please let me know if the topic is still free.

 Thanks in advance,
 Matej


 [1] http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS

2015-04-28 Thread Newcomb, Doug
Thank you for working on this! :-)

Doug

On Tue, Apr 28, 2015 at 2:16 PM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,
 Thanks for the chance to participate on GSOC 2015. The page about project
 is on wiki site[1]. Thank you for ideas and notes in advance.

 Matej

 [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

 2015-03-11 1:55 GMT+01:00 Matej Krejci matejkre...@gmail.com:

 Hi all,

 Last GSOC I was working on ISO based metadata management for GRASS. In
 this term I was created 'package' wx.metadata which is currently available
 in GRASS add-ons. This part was essential. During playing with
 possibilities of implementation I did a draft of metadata catalogue which
 is the main task of current GSOC topic[1]. Moreover to implement additional
 functions (see list[1]) for current metadata modules is more than suitable.
 Since last GSOC I am still slightly in coding for GRASS and I like to
 continue in this topic. Please let me know if the topic is still free.

 Thanks in advance,
 Matej


 [1]
 http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS



 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev




-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS

2015-04-28 Thread Paulo van Breugel
Is the addon working in GRASS 7.1? I can't compile it.


On Tue, Apr 28, 2015 at 8:16 PM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,
 Thanks for the chance to participate on GSOC 2015. The page about project
 is on wiki site[1]. Thank you for ideas and notes in advance.

 Matej

 [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

 2015-03-11 1:55 GMT+01:00 Matej Krejci matejkre...@gmail.com:

 Hi all,

 Last GSOC I was working on ISO based metadata management for GRASS. In
 this term I was created 'package' wx.metadata which is currently available
 in GRASS add-ons. This part was essential. During playing with
 possibilities of implementation I did a draft of metadata catalogue which
 is the main task of current GSOC topic[1]. Moreover to implement additional
 functions (see list[1]) for current metadata modules is more than suitable.
 Since last GSOC I am still slightly in coding for GRASS and I like to
 continue in this topic. Please let me know if the topic is still free.

 Thanks in advance,
 Matej


 [1]
 http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS



 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev