reclassify tool

[12rambau]

@dfguerrerom, first thank you for what you did, I love the idea of stand alone tiles.

I have done several refactoring steps that I will list here (I may forget some of them):

• remove the widgets and set them directly in the view files
• stop using the model in the table_view (it's useless as we are producing a file that will be then read by the reclassify view
• remove the output widget for all the dialogs
• remove the text for now (it think we could set it back once we are happy with the rest of the interface)
• forcing the model to be compatible with everything using nested function. one for each behaviour: vector and image both in ee and local
• revert the way we select values: use the destination values and set a list of previous value
• there were a map_ member but it was never used so I removed it
• I default the folder search to home()for nearly everything

Question:

• What do you think of the new model structure ? do you see any other way to handle all the possible file type ?
• I think there is still room for inprovement in the interface display, be my guet if you have ideas (as I mentioned earlier, I think the text should be set at the very very end)
• I am uncomfortable with the folder selection (when and where should it be set). At the mooment I think it's not functional
• The more I play with it the more I have the feeling that the reclassify and the table could be fully independant tile. For example in GWB I want the reclassify table and that's all, I will be imposing the reclassification file (same for SDGs) what do you think ?

I'll continue playing with it but I think we should use this conversation to see where we want to go

[dfguerrerom]

@12rambau thank you for the code reviewing and the new implementation, the new cosmetic table interface looks very sepal.
There are some comments that I would like to share with you.

• I like how we are reducing the number of widgets by changing the order of the reclassification, however, I'm not feeling comfortable when reclassifying a real users/dafguerrerom/FAO/LULC_2012_AOI land cover asset with several classes, the user will have to do lots of clicks to reclassify it instead of using tab key to change the value —I was inspired by the ArcGis/QGis implementations—.
• In the previous version we had the option to store the reclassification map values into a file, and using them later with a new dataset, so the user doesn't have to do the process manually again, could we implement it again?.
• I know that we have a file explorer widget, however, it could become difficult for a new user with lots of folders to search a file, what do you think if we left both options? a dropdown widget with tentative look up locations and store there some predefined tables, such a binary or ipcc and the file explorer to do a more exhaustive search?.

I think that's all...

[12rambau]

I like how we are reducing the number of widgets by changing the order of the reclassification, however, I'm not feeling comfortable when reclassifying a real users/dafguerrerom/FAO/LULC_2012_AOI land cover asset with several classes, the user will have to do lots of clicks to reclassify it instead of using tab key to change the value —I was inspired by the ArcGis/QGis implementations—.

To have more people advice on this matter I took the liberty to show the final product to Rémi and Yelena. Of course Rémi like this implementation (as it was one of his suggestion) and Yelena prefers yours. 2 VS 2 that's what we call a draw... BUT if that's the QGIS way then we align on QGIS, there are more people out there that know how to use it. I'll rollback to the initial order with a max-heigh params to limit the number of displayed lines

• Do we want to enforce to remap every class ? (that was the case in your implementation but we can as well put set them to no-data)

In the previous version we had the option to store the reclassification map values into a file, and using them later with a new dataset, so the user doesn't have to do the process manually again, could we implement it again?.

I didn't think about this application. So someone is using the same classification but on different places right ?
I'll definitly roll it back as well

I know that we have a file explorer widget, however, it could become difficult for a new user with lots of folders to search a file, what do you think if we left both options? a dropdown widget with tentative look up locations and store there some predefined tables, such a binary or ipcc and the file explorer to do a more exhaustive search?.

So this one is tricky because my objective was to reuse this component in other app. Let's take sdg as an example: the destination is known: it's IPCC. So whatever your input I want to force the user to use IPPC a a destination. As a developer you set the default_class param and the FileInput widgets disappear all together.

But in apps with more liberty people may like to use default one. A first trick is to use class_path to point to a specific folder, so that you just navigate within a menu. I'm not in favor of the dropdown as it blocks the user in a specific folder, BUT what I like is the idea to save default one in your app. What would you think to them on top/bottom of the FilleInput:

when clicked the btn would force set the value in the file selector. My guess is that whatever the application there won't be more than 4-5 defaults so it will fit the display

addition from @yfinegold:

• offer the opportunity to load a csv of the original classification to display both the name and the code
• read 2 columns in vector to obtain the name and the code
• increase table header size (they are smaller than the text) even though it's a vuetify feature
• improve the function that reads csv/txt to allow more complex format (I still need to wrap my head around this one because there is an infinity of possibilities)

Long story short, I'll code again in this branch today ;-)

[dfguerrerom]

Do we want to enforce to remap every class ? (that was the case in your implementation but we can as well put set them to no-data)

Yes, definitely we don't want to force users to reclassify all the values, so we can set them as no-data, I agree with that, but perhaps would be nice to have a message alerting the user that.

I didn't think about this application. So someone is using the same classification but on different places right?

Right! the option was in the reclassify pop-up dialog, so after someone finished the reclassification process, there was the option to save it in a file, and use it later with a new dataset having the same values (by changing its v_model)...

when clicked the btn would force set the value in the file selector. My guess is that whatever the application there won't be more than 4-5 defaults so it will fit the display

Well, I think that this implementation is very nice ;), easy and useful.

[dfguerrerom]

I'm not sure if here would be the best place to comment this or if I should open an issue (you'll tell me).

By reviewing the code I noticed that the schema is stored in the translation, I think that we should avoid using translated keys as variables, so in that case, we could define the scheme in the ClassTable or in the TableView and reference their labels in the translation files, what do you think? When I was coding this element I saw the potential of using it as a native sepal_ui widget, so we could use it in new apps, and that was one of the reasons to have a dynamic scheme.

[12rambau]

I think you're right, I'm doing the same mistake as in se.plan, I'll replace it with a dict as in the aoi_view.

But I don't see the potential of having an editable scheme. I have more the feeling that lots of additional work will be needed to convert file to class dataframe but that the final classification system would use an homogeneous 3 column scheme

[dfguerrerom]

Ok, perfect.
Well, I'm not actually talking about using the table only for the reclassify tile but for a wider range of applications that would require a custom table created within the app, however, I think that for the reclassify app, the current state looks perfect!.

[12rambau]

ah ok so you were thinking of a CRUD system right ?

[dfguerrerom]

(I had to google it), but yes... a more generic widget to do CRUD operations (with txt files so far), that would require a dynamic schema.

[12rambau]

I would say next big widget, when we clean a bit the pile of bug/improvement. but yeah open an issue definitely

[12rambau]

• rollback to the previous table implementation, you can jump from widget to widget using tab. I don't enforce the reclassification of all values
• you can save a import an already applied matrix. The file cannot be used if the table have not already been generated (meaning that you still need to set up the file, the band, and the dst table)
• set default class file that will be displayed as btn
• load the source csv
• I decided not to read vector files because it's too many if statement and at some point I also want people to prepare their data ;-)
• cosmetic improvement to improve the workflow and UX
• cannot increase header size within vuetify (we don't have access to the css)