Re: [GRASS-dev] Management of signature files
On Wed, 28 Apr 2021 at 13:34, Maris Nartiss wrote: > > Hello Luca, Hi Maris, > I would also love to hear your personal vote on an approach we should > take with signature management tools in G8. > I think Vaclav's words are perfect and I quote entirely them. Probably I like more a set of tools external from g.* > > I guess same applies to copy and remove too. At least i.signatures.* > case is a bit better as these are specific tools for the task and thus > an extra option of "signature type" can be added to distinguish sig > from sigset. > yes > > Māris. -- ciao Luca www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Management of signature files
Hi Marias Thanks for initiating this. On Tue, Apr 27, 2021 at 8:44 AM Maris Nartiss wrote: > > > > Hello list, > > I have been working on moving automatic classification signature files > > (ones used by i.maxlik and i.smap) out of imagery groups. Existing > > approach was not flexible enough as there was no official way of how > > to reuse signatures from one imagery group in another group (train on > > one, classify many). > > > > #4 A variation of #3. Change signature storage to > > "/signatures/." Pro: easy to > > add to g.* tools with element syntax ".(@)". > > Con: needs special handling in GUI (show items matching SIG_TYPE); > > element syntax differs from other data elements. > I would prefer the #4 option as it will align with the rest of the data handling using "g." modules. It would be also nice to have an option to save the signature file to a text file. On a related topic, the final output from i.maxlik is added to the input group by default. Can we also change this behaviour? Regards Sajid ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Management of signature files
Hi Maris, Here are my thoughts about the signature files. On Tue, Apr 27, 2021 at 2:44 AM Maris Nartiss wrote: > > #2 A variation of #1. Add a separate signature file management tool > (i.signatures?). ... one has to remember to use a > special module that differs from the rest (vect, raster, raster3d)... > > #4 A variation of #3. Change signature storage to > "/signatures/." Pro: easy to > add to g.* tools with element syntax ".(@)". > Con: needs special handling in GUI (show items matching SIG_TYPE); > element syntax differs from other data elements. > I'm for using file extensions and a separate set of tools, so combination of your #4 and #2. As you say, /signatures/subdir/file extends the basic GRASS locatio structure anyway. Extensions are a general concept which we will just apply here. It could work for other things as well. You could have, e.g., /vector//hist.yaml. I don't know how much to show the type (extension) in case of signatures. I think it depends on how much the tools will deal with signatures of the wrong type for them. Having extensions in place may help when you decide you want standalone signatures outside of GRASS location. A separate set of tools may be actually less confusing, but that really depends on what each user expects from g.list. Should everything be handled by g.list, e.g., tools installed from addons? Of course not. If you need to work with signature files, you will get to a list of necessary tools somewhere. If you don't, you are not distracted by that. As an alternative to both extensions and subdirectories, you could change the format to something which each tool can easily recognize as something readable or unreadable like having a first line "format: sigset". Each tool needs to write it and check it, but from a file management perspective it all formats are the same. Whichever path you take, I like that you are revising this! Best, Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Management of signature files
Hello Luca, I would also love to hear your personal vote on an approach we should take with signature management tools in G8. 2021-04-28 13:33 GMT+03:00, Luca Delucchi : > Hi Maris, > > On Wed, 28 Apr 2021 at 07:38, Maris Nartiss wrote: >> >> These are only band-aids for current situation. >> i.signature.copy is dangerous to use – one has to be certain that >> raster map order in REF files of both groups match. If one group has >> different order, it still will copy over signature file without >> complaints (think – use data of green band to analyse content of red >> band). > > I opened a ticket https://github.com/OSGeo/grass-addons/issues/517 if > you have any better idea please add it to the issue Warning would do as there is nothing you can do without checking band references but they are not available in GRASS 7. >> i.signature.list only lists signatures of type sig but ignores sigset >> – nothing to see here. >> > https://github.com/OSGeo/grass-addons/issues/518 I guess same applies to copy and remove too. At least i.signatures.* case is a bit better as these are specific tools for the task and thus an extra option of "signature type" can be added to distinguish sig from sigset. >> Māris. > Luca Māris. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Management of signature files
Hi Maris, On Wed, 28 Apr 2021 at 07:38, Maris Nartiss wrote: > > These are only band-aids for current situation. > i.signature.copy is dangerous to use – one has to be certain that > raster map order in REF files of both groups match. If one group has > different order, it still will copy over signature file without > complaints (think – use data of green band to analyse content of red > band). I opened a ticket https://github.com/OSGeo/grass-addons/issues/517 if you have any better idea please add it to the issue > i.signature.list only lists signatures of type sig but ignores sigset > – nothing to see here. > https://github.com/OSGeo/grass-addons/issues/518 > > Māris. > -- ciao Luca www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Management of signature files
Hello Veronica. Thank you for your reply. 2021-04-27 15:22 GMT+03:00, Veronica Andreo : > There are 3 add-ons that Luca wrote at OSGeo code sprint in Bonn 2018: > i.signature.copy, i.signature.list, i.signature.remove. > Would they be of help for any of the options proposed? These are only band-aids for current situation. i.signature.copy is dangerous to use – one has to be certain that raster map order in REF files of both groups match. If one group has different order, it still will copy over signature file without complaints (think – use data of green band to analyse content of red band). i.signature.list only lists signatures of type sig but ignores sigset – nothing to see here. Thank you for this comment, but it is more about what we call "doing the right thing" than how to implement it. > In any case, thanks for your impressive work! Its not over yet. > Cheers, > Vero Māris. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Management of signature files
Hi Maris, El mar, 27 abr 2021 a las 8:44, Maris Nartiss () escribió: > Hello list, > I have been working on moving automatic classification signature files > (ones used by i.maxlik and i.smap) out of imagery groups. Existing > approach was not flexible enough as there was no official way of how > to reuse signatures from one imagery group in another group (train on > one, classify many). > At the moment I have managed to implement all internal bits of fully > reusable signatures – at the time of creation, band references are > written to the signature file; before signature use, band references > are used to reorder signatures to match band order in the new group > (or bail out if bands do not match). > https://github.com/OSGeo/grass/pull/1501 > > There are only two bits left before this work is complete: > 1) remove current special signature file handling in GUI; > 2) signature management. > There are 3 add-ons that Luca wrote at OSGeo code sprint in Bonn 2018: i.signature.copy, i.signature.list, i.signature.remove. Would they be of help for any of the options proposed? In any case, thanks for your impressive work! Cheers, Vero ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Management of signature files
Hello list, I have been working on moving automatic classification signature files (ones used by i.maxlik and i.smap) out of imagery groups. Existing approach was not flexible enough as there was no official way of how to reuse signatures from one imagery group in another group (train on one, classify many). At the moment I have managed to implement all internal bits of fully reusable signatures – at the time of creation, band references are written to the signature file; before signature use, band references are used to reorder signatures to match band order in the new group (or bail out if bands do not match). https://github.com/OSGeo/grass/pull/1501 There are only two bits left before this work is complete: 1) remove current special signature file handling in GUI; 2) signature management. I would like to hear some feedback on how to proceed with signature management. At the moment I have placed signature files into following structure: ///signatures// As you can see, this structure differs from the canonical GRASS approach of having single level to represent type (e.g. raster, vector, ...) as there is a need to differentiate various signature file types (at the moment there are two types – sig and sigset. I'll finish work on a third (svm) after merging this PR). Options for signature file managemet are: #1 In GRASS 7 there are no options to manage signature files at all. Once file is created, it can be only removed with OS file management tools. g.list|copy|rename|remove have no idea of signature files. Pro: easy to implement (=works already). Con: poking around mapset should be done only by those who understand consequences. #2 A variation of #1. Add a separate signature file management tool (i.signatures?). We do have a precedent already – imagery groups are managed by i.group module as g.* modules only see group but not subgroups inside a group; time datasets. Pro: still easy to implement. Con: needs special handling in GUI; one has to remember to use a special module that differs from the rest (vect, raster, raster3d). #3 Modify management library (g.* tools) to accept two level specifiers e.g. "/(@)". Pro: one can use usual g.* tools as with other data elements. Con: tricky to implement without significant changes to lib/management; needs special handling in GUI (show items matching SIG_TYPE); element syntax differs from other data elements. #4 A variation of #3. Change signature storage to "/signatures/." Pro: easy to add to g.* tools with element syntax ".(@)". Con: needs special handling in GUI (show items matching SIG_TYPE); element syntax differs from other data elements. Let me know your preferred option or other ideas regarding signature files. When I started to work on the issue, I was leaning towards #3 but now #4 seems to be even easier from implementation point of view, although #2 is always an option. After merging this PR, I have only r.in.pdal on my agenda and then I'll remind everyone that GRASS 8.0 is long overdue ;-) Māris. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
