Open ninsbl opened 5 months ago
@wenzeslaus which avenue do you suggest we follow here?
I could add a python function myself (e.g. in an imagery module in grass.script
), but I am not good enough with C to implement more sophisticated printing in i.group. Do you think this could be addressed by @kritibirda26 as part of the JSON GSoC project (you probably have a full schedule already)?
@marisn do you have any suggestions / comments here? You did quite some work on imagery groups recently...
On a second thought, since I do need the full raster info and not only the semantic label of maps in a group for my use-case anyway, a python function is probably more suitable / appropriate...
Wrapper function vs JSON output: Many wrapper functions in grass.script are mainly workarounds for missing JSON output (and avoid strange syntax). I would have to check to see the priorities for GSoC.
If you need to wrap multiple tools together, then the question is if we want that as a function in grass.script. Of course, that does not remove the need for JSON output of i.group.
As i.group does not have a JSON output, we are free to implement as we wish. It does not contradict of having a Python function too. I probably would not touch existing print flags to not break backward compatibility but just implement a new print functionality. I think we should go with a plain G_OPT_F_FORMAT option – when it is set, we print, when absent – don't. Back in a day there was an initiative to abandon subgroups (too lazy to search in Trac for #) and thus I would probably go for printing group and all its subgroups in one go ignoring subgroup parameter. As for the actual JSON structure I do not have any preference at the moment as I haven't tried to implement any code where it would be required and thus I do not see how it should look. Only we must keep in mind that not all rasters have a semantic label.
Is your feature request related to a problem? Please describe. The concept of semantic labels got introduced with the temporal framework, were it`s original idea was to flag bands in e.g. satellite imagery. However, this concept can be very handy when handling all kinds of imagery data.
In order to make better use of it in the imagery group context, it would be great if
i.group
could print not only the maps in a group, but also their semantic labels. In scripts I use a python function to get the the semantic labels of maps in a group (see below), and I was thinking about adding it to the python library, However, looking at i.group, I think it would be more appropriate/convenient to extend the printing functionality of the i.group module.Describe the solution you'd like i.group allows printing of files in (sub) groups (-l) as well as subgroups (-s) in verbose and "shell script" style (
-g
), which actually is rather a plain list. What I would like to see is: a) either a new flag (e.g. -S) to request printing of semantic labels of the maps in the group or a print option (instead of the -l and -s flags) and b) a _G_OPT_FFORMAT option to request different output formats (instead of the -g flag).Ideally, the current flags for printing get deprecated (but kept functional (with a warning to the user) until rempoval) in favor of a combination of print and format option
So, I would like to be able to do something like this:
And then
Which should return something along the following lines:
or
Which should return something along the following lines:
or
Which should return something along the following lines assuming two subgroups (if subgroups are still relevant):
or
Which should return something along the following lines:
Describe alternatives you've considered An alternative would be to add a function to the Python library, like the following:
Additional context The background is the need to match imagery groups to machine learning models using the semantic labels of an imagery group (instead of e.g. relying on the order of the maps in the group).