<div dir="ltr"><div dir="ltr">Hi Maris,</div><div dir="ltr"><br></div><div>Here are my thoughts about the signature files.<br> </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 27, 2021 at 2:44 AM Maris Nartiss <<a href="mailto:maris.gis@gmail.com" target="_blank">maris.gis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
#2 A variation of #1. Add a separate signature file management tool<br>
(i.signatures?). ... one has to remember to use a<br>
special module that differs from the rest (vect, raster, raster3d)...<br>
<br>
#4 A variation of #3. Change signature storage to<br>
"<MAPSET>/signatures/<signature file name>.<SIG_TYPE>" Pro: easy to<br>
add to g.* tools with element syntax "<name>.<SIG_TYPE>(@<MAPSET>)".<br>
Con: needs special handling in GUI (show items matching SIG_TYPE);<br>
element syntax differs from other data elements.<br></blockquote><div><br></div><div></div><div>I'm for using file extensions and a separate set of tools, so combination of your #4 and #2.</div><div><br></div><div>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., <MAPSET>/vector/<name>/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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> <br></div><div>Whichever path you take, I like that you are revising this!<br></div><div><br></div><div>Best,<br></div><div>Vaclav<br></div></div></div>