g.region: revision of output formats about grass HOT 3 OPEN

See #3020 for tracking modules that need JSON/YAML output.

from grass.

Random ideas

• Adding a new standard option (e.g., G_OPT_M_FORMAT)
• Implementing a new library function for format translations (e.g., G_translate_format())
• Maybe, some more utility functions to generate JSON objects (would this format be the most complex and expressible format for GRASS?)
• Individual modules only generate JSON outputs (the superset of all formats) and use G_translate_format() to produce other formats

from grass.

A lot of tools need key value format, so some universal translating function would work. Another group might be table data. Some tools would have to keep their own formats at least if we want to stay compatible. The human readable output is also important. YAML can sometimes count like that.

What is funny is that GRASS GIS is using basically YAML files since 80s to store things internally. Internal WIND file looks like this:

proj:       99
zone:       0
north:      221230
south:      219580
east:       639530
west:       637740
cols:       179
rows:       165
e-w resol:  10
n-s resol:  10
top:        1
bottom:     0
cols3:      179
rows3:      165
depths:     1
e-w resol3: 10
n-s resol3: 10
t-b resol:  1

But for machine readable output, it gets translated to:

projection=99
zone=0
n=221230
s=219580
w=637740
e=639530
nsres=10
ewres=10
rows=165
cols=179
cells=29535

which was designed for Bash eval and similar usage, but these days most people would likely choose JSON or YAML as sort of the default machine readable format for this data. Same for raster cellhd and vector head files and what r.info and v.info produce.

  __________________
/    GRASS GIS       \
\        is yamly!   /
  -------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
_\|/__\|/__\|/_ ||     ||  _\|/__\|/_

from grass.