Inline Classification

[spaine916]

This is my first time suggesting an enhancement so let me know if this is appropriate. I am attaching a PDF that describes the enhancement request.

Inline_Classification.pdf

[petrasovaa]

I suggest to explain the enhancement in the description, this will make it more likely people will read it. Be sure to describe the context of your suggested enhancement, e.g. what is the current state and why do you want to enhance it and how. Is this something you will work on?

[spaine916]

Anna

Thanks for the feedback. I will edit the submission and attached document with a better definition with specific GRASS context and repost it.

If anyone is looking at this submission, please wait for the next round.

I am not proposing to code this up as I lack the required programming skills to deal with all the aspects of this enhancement. I would happily work with anyone who would like to implement this to provide clarification or additional information.

Steven

[spaine916]

Anna I have a number of questions about how to propose enhancements when they are implemented across the whole system. This issue was set up to propose a specific enhancement. Is this the right forum to have a back-and-forth discussion on the broader topic? I would be happy to go offline via email, chat or phone call if that makes sense. My email is: ***@***.*** Thanks for you time on this. Steven

…

________________________________ From: Anna Petrasova ***@***.***> Sent: Monday, November 4, 2024 7:52 PM To: OSGeo/grass ***@***.***> Cc: spaine916 ***@***.***>; Author ***@***.***> Subject: Re: [OSGeo/grass] Inline Classification (Issue #4649) I suggest to explain the enhancement in the description, this will make it more likely people will read it. Be sure to describe the context of your suggested enhancement, e.g. what is the current state and why do you want to enhance it and how. Is this something you will work on? — Reply to this email directly, view it on GitHub<#4649 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BMVJ6YJE4FYVYL6P3LTXAGTZ7AXGHAVCNFSM6AAAAABRFN74ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJWGE3TKMRZGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[petrasovaa]

You can either post it here or post it on our developer forum, but keep it public. It looks like you are proposing a major feature, so to make the discussion productive, think about what can be done with available resources.

[spaine916]

Ok here is the proposed enhancement in the standard format.

I have been running GRASS to try the various existing functionality, but I am by no means an expert so my understanding of how things work may be off. I am also working on my own and have been operating in my own little echo chamber so I would appreciate some feedback.

Thanks

Steven

Is your feature request related to a problem? Please describe.

Description
To use many data sets in the GIS it is necessary to create intermediate data sets that can be used for analysis and display. This process takes time and has to be done in advance of using the data. Once the intermediate data is created it is static and it is often difficult to know how they were created. These intermediate data sets are often only used for one specific process or single execution. So, if a user is developing a process or running what-if scenarios for analysis the definition, creation and use of intermediate data sets is time consuming and error prone.

Describe the solution you'd like

I’d like to be able to create a complete definition of any data for processing and display that can be easily created and used at runtime for any process or function in the GIS. A complete definition would include color assignments, weights and descriptions and would be easy to read in a GUI field or a command line.
The data classes defined for display, classification and analysis are often the same. This proposed enhancement would add the ability to define the ranges, colors, weights and descriptions in one place so that the relationship between them is easy to see.
There are three components to this enhancement.
• Create a single definition of the classes with a naming convention that shows the complete definition of a data set when it is used.
• Provide the ability to use these classes at run time for display, analysis and command line operations without any data processing to prepare the data.
• Finally, add the ability to use conditional definitions (classes) in all the functions in the GIS without having to change the core function operation.
This should significantly reduce or eliminate the need for intermediate data sets.

Describe alternatives you've considered

Using the various classification functions in GRASS (v.category , r.category, v.class, r.class, r.desribe, r.colors, v.colors) which can be time consuming, error prone and not very functional for defining processes or what-if scenarios.

Additional context,

Requirements

The main requirement is to use the original data sets and add value-added information when needed, to reduce the need for intermediate datasets. The objective is to create easy to use definitions and execution with a GUI interface for all operations.
To meet the functional requirements this design must meet the following requirements:
• Have a single source of classification definition (colour, weights, descriptions) in one easy to use operation. This is a combination of the existing colour and category functionality into a single complete data definition.
• Provide runtime class assignments in all functions in the GUI and command lines, that are applied when a function is executed similar to r.reclass operations but without the prework.
• Be able to read a data definition in a GUI field or on a command line and understand what the core data are and any modifications made to them.
• Provide the ability to have multiple classification tables for each data layer.
• Minimize the impact of introducing the new functionality in the GIS system.
• Minimize the impact on any existing functions that will utilize the new functionality.
• Provide additional functionality to existing functions without changing their core operations.

Class Tables

GRASS already has an interactive class table creation function in the display window that is used to define the visual presentation of selected covers by defining ranges, single values or character classes and assigning colours to them with a colour number or an HSL / RGB definition in the Col columns. This function specifies the input data cover and either uses their numeric values or an attribute that holds the values to be classified. There is also functionality that associates the source data with its table definitions.
To implement the class table definition two new columns could be introduced into the editor that allows a user to enter their own user defined numeric weight values (Wt) and a text description (Des) associated with each range.
The advantage of using the color assignment functionality is that the data and conditions are easily displayed with their assigned colors for visual validation of the assignments and it is easy to see the results for any subsequent changes. The existing color assignment functionality can already assign ranges, single values or character descriptions to values in an input data layer, associate multiple tables to an input data layer and provide functionality to retrieve a requested table.
The goal is to present a single easy to use GUI interface to users to define the class ranges with their color, weight and description values.

Data Definition
To get a complete data definition it needs any color assignments, weights or descriptions displayed and used for processing.
The proposed naming convention would be:
[email protected]
This looks like quite a long complex name to deal with but it would usually be much simpler as the ClassTableColumn values would be Col, Wt, Des and would default to Wt. The following examples are listed below with the expected most common usage first.
• Slope
• Slope@Erode8
• Soils.Type@SoilPercRate
• [email protected]
• [email protected]]
The advantage is that by reading the name a user would know the core data and any modifications being made to them. Any functions using this data would also be able to use this name to process the data with the modifications defined.
Implementation
To implement this enhancement would require a change to the core GetData function(s). If the existing GetData functions accept a string for the data definition then they could be enhanced as the following
Read in the new definition of the data the same way it reads them now.
• Add methodology to parse the input string to get the DataName, AttributeName (if there), ClassTableName (if there) and ClassTableColumn (if there).
• Get the data value the same way as now.
• Put the data value through the class table to get its assigned column value.
• Return the adjusted value to the calling routine.
If this could be done this way it would make the changes transparent to the functions using the data and provide backwards compatibility.
The big change would be in the function GUIs where there would need to be two new controls added to every function’s GUI. The first one would be a scrolling field that would display the available class tables for the function. The second one would be a scrolling field that would display the three column names (Col,Wt,Des) for selection.
Then on selection the GUI would create the complete data name and display it in the input data selection field. On execution the complete name would be passed to the GetData function as described above.

Issues
Some of the assumptions made here could be wrong.
The amount of work it takes to implement the changes are probably optimistic.
It could be possible to implement the backend changes for command line processing as a plugin, but the GUI changes would probably need to be included in the product.