[GRASS-dev] Introduction for GSoC 2017

[Moritz Lennert]

Le 15 mars 2017 04:26:53 GMT+01:00, Vaclav Petras <wenzeslaus at gmail.com> a écrit :
>Dear Moritz and students,
>
>here are some of my ideas for these ideas. This is a good start. I
>think we
>need enhancement ticket with use cases for each item.
>
>On Tue, Mar 14, 2017 at 6:25 AM, Moritz Lennert <
>mlennert at club.worldonline.be> wrote:
>
>> - A general vector interactive attribute table editor which pops
>>   up an attribute editing form when you click on a vector map.
>>   Currently, to do this, you have to go into digitizing mode.
>>
>
>This is what the original query dialog in GUI was doing, but then it
>was
>replaced by something which is optimized for (ready only) queries and
>does
>not allow editing. You need to specify how the editing dialog would be
>connected to the current GUI; e.g. new button?

A button in the GUI (e.g. within a query menu) would be nice, but it could possibly also be implemented as a g.gui.* module.

>
>
>> In
>>   addition, it would be great to be able to somehow (text input file
>?)
>>   be able to define the columns you see in the form so that you don't
>>   have to scroll through tens of lines before you reach those that
>you
>>   want to edit.
>>
>
>Is a text file the user friendly way you are looking for? Should this
>be
>stored between GUI sessions?

I find text files the most versatile, accessible and easy to handle by everyone, but I guess I'm a bit old school ;-). All it would need is a list of column names (unless we want to allow defining column input widget types). If time allows we could create another module that allows creating this file.


>
>
>> - A tool to attribute class values to raster objects. This is much
>>   simpler and "just" a combination of GUI + r.what + form to add a
>>   value + writing everything to a text file. In other words, it is
>the
>>   current GUI raster interrogation tool enhanced to add a value and
>to
>>   write info to a file.
>>
>
>This sounds like raster attribute table for GRASS GIS. This needs some
>serious design.

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).


>
>There is more of these individual features which may be useful, e.g.
>imagery group support in the Data tab or r.pack/r.unpack equivalent for
>imagery groups.
> Also the GUI dialog which shows for (instead of)
>i.group
>needs some improvements.


The r.pack/unpack idea sounds great. I haven't really encountered problems with the others, so I'd leave that to you. We just need to make sure we don't increase the number of tasks too much.

I think the rules editor that is also part of the proposal will take some work and thought...


>
>
>Moritz and all,
>
>in cases like this, when a GSoC idea can be split into a separate
>features
>and they are reasonable feature requests (they wouldn't be part of the
>idea
>otherwise, right?), it would be good if we create the appropriate
>tickets
>for each of those. We did this last summer when we used keywords (tags)
>`gsoc2016` and `cartography` for each ticket related to the GSoC
>Cartography Improvements idea:
>
>https://trac.osgeo.org/grass/query?status=assigned&status=
>closed&status=new&status=reopened&keywords=~gsoc2016+cartography
>
>For this idea it could be e.g. `gsoc2017` and `ImageAnalysisGUI`, but
>please suggest something better (it must be one word, no spaces).

+1

Do you think we should create these tickets now, or as part of the first phase of the project ?

Moritz