<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 15, 2017 at 3:00 AM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
><br>
>> - A tool to attribute class values to raster objects. This is much<br>
>>   simpler and "just" a combination of GUI + r.what + form to add a<br>
>>   value + writing everything to a text file. In other words, it is<br>
>the<br>
>>   current GUI raster interrogation tool enhanced to add a value and<br>
>to<br>
>>   write info to a file.<br>
>><br>
><br>
>This sounds like raster attribute table for GRASS GIS. This needs some<br>
>serious design.<br>
<br>
</span>No, I was not aiming for raster attribute tables. The main motivation for me is that when you create segments in an object-based image analysis approach and you want to then extract some objects as training objects this is currently not easy to do. For such training you have to identify the objects and indicate which class they're in. My idea is not to store this info within the gisdbase, but to output it to text file (yes, again ;-)) which can then be used as input to further treatment (e.g. v.class.mlR & co).<br>
<span class=""><br>
<br></span></blockquote><div><br></div><div>I don't say that this can't be implemented through external CSV files and the tools for handling them and transferring raster values into them are generally useful. The thing I'm uncomfortable about is that it looks like a raster attribute table from user point of view but it is different and also at one point CSV won't be enough for some they will need actual database or SQL. We had ASCII vectors in the past... (not that I would be around for that ;-)<br></div><div><br><span class=""></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>Moritz and all,<br>
><br>
>in cases like this, when a GSoC idea can be split into a separate<br>
>features<br>
>and they are reasonable feature requests (they wouldn't be part of the<br>
>idea<br>
>otherwise, right?), it would be good if we create the appropriate<br>
>tickets<br>
>for each of those. We did this last summer when we used keywords (tags)<br>
>`gsoc2016` and `cartography` for each ticket related to the GSoC<br>
>Cartography Improvements idea:<br>
><br>
><a href="https://trac.osgeo.org/grass/query?status=assigned&status=" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>query?status=assigned&status=</a><br>
>closed&status=new&status=<wbr>reopened&keywords=~gsoc2016+<wbr>cartography<br>
><br>
>For this idea it could be e.g. `gsoc2017` and `ImageAnalysisGUI`, but<br>
>please suggest something better (it must be one word, no spaces).<br>
<br>
</span>+1<br>
<br>
Do you think we should create these tickets now, or as part of the first phase of the project ?</blockquote></div><br><br></div><div class="gmail_extra">Yes, now.<br></div></div>