Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

g.region: revision of output formats #3410

Open
echoix opened this issue Feb 8, 2024 · 3 comments
Open

g.region: revision of output formats #3410

echoix opened this issue Feb 8, 2024 · 3 comments
Labels
C Related code is in C enhancement New feature or request module

Comments

@echoix
Copy link
Member

echoix commented Feb 8, 2024

There are print flags that add information (-l, -e, -c, -n, -3, -b). I don't think all of them are printed in flat format on 1 line with this PR yet.

I think that falls into the general revision of all output formats below.

I agree the -f flag should stand on its own in the same way you don't have to use -g flag together with -p flag.

I also expect that. -g usually means "key=value" line by line in other tools and there are no modifications to the format.

Ultimately we could introduce some kind of format method to include json format and get rid of all these flags?

That would be ideal.

Originally posted by @wenzeslaus in #3216 (comment)

@petrasovaa petrasovaa changed the title General revision of output formats g.region: revision of output formats Feb 8, 2024
@petrasovaa
Copy link
Contributor

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

@petrasovaa petrasovaa added C Related code is in C module labels Feb 8, 2024
@HuidaeCho
Copy link
Member

HuidaeCho commented Feb 21, 2024

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

@HuidaeCho HuidaeCho added the enhancement New feature or request label Feb 21, 2024
@wenzeslaus
Copy link
Member

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 |
_\|/__\|/__\|/_ ||     ||  _\|/__\|/_

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C Related code is in C enhancement New feature or request module
Projects
None yet
Development

No branches or pull requests

4 participants