Local AOI Tile

[dfguerrerom]

Here is the first draft of a possible local aoi implementation, I tried to be the more explicit as I can to document the idea, I tried to follow your way to code the view and the io classes, please check it out the jupyter notebook and let me know your questions.

• I implemented the way as a user could upload a shapefile and then select features inside it.
• I made the selection widgets independent from the map, so the developer will decide where to display it, and in some cases there is no need to have a map.

https://github.com/12rambau/sepal_ui/blob/local_aoi/sepal_ui/aoi/local_aoi.ipynb.

[12rambau]

so if I get the architecture clearly :

• AoiModel would be an io
• AoiView manage the btn and everything that was runnning in run_aoi_selection (it can be combined with a map)

sounds like pure MVC to me ;-)

I would of course add a AoiLocalTile that would wrap these two compoent for those who need a fully independant one).

I'll see what I can do for the country list with GADM

Sorry but I have several deadlines in the following week I'll see how I can catch up ...

[12rambau]

Ok i've tested what is available so foar and I have few comments :

• The sepal map is dependant to EE, we need to modify it
• I think we need to build a aoi_tile as well for the sake of begginer
• I will add the contries with GADM
• I think the catch_error function need to go somewhere else it will be usefull everywhere. On the other hand, the one that toogle the btn cannot be scaled. Some processes need to toggle multiple btn at the same time and/or release btn in other tiles.
• I think that to avoid complexity all the aoi related files should live in the aoi folder without submodule (we need to agree on a structure)
• looking at it I was also thinking to the following : in the init we create "meta" fonctions for tile/model/view with an "ee" arguments and it calls the right one. It makes it transparent for the end user. (It will just be more complicated to document)

[dfguerrerom]

In the last commits, I've noticed the following:

• I guess that VectorField is just an element of the local_aoi, I don't think that it will be used in other places (I might be wrong), so would be better if we left it in the aoi_view definition.
• To make the code cleaner, would be better to move the VectorField methods that are using geopandas or any other vector manipulation directly to the model, and doing so we could handle and catch the errors there, not in the view.
• We could test saving the csv files in a pickle format, I've read, and seems to be more light and opening faster by pandas.
• I've changed the clear method from sepalwidgets to reset, it's mainly because the FileInput object was redefining this method, and that's why the widgets were being displayed so slowly, we have of course other alternatives, such as change those methods, but since I don't know how deep are them in the other apps, I chose for change the new sepalwidget clear name.
• I've removed the json load/dumps, since there is no need to use them due the v_model definition is a dictionary
• I have to say that I don't like the way we are passing the variables from view to model by using an alert, would be better to do in a direct way.

[12rambau]

• I've already used VectorField (or something approaching) in other apps (si I would say it's not very costly to leave it there) I still need to do some little gdf manipulation to it in order to read the columns but I'm definitely not force to save it.
• I remember trying to use the Dictionnary traitlet and it didn't work (I wasn't able to listen to changes). If you say it's possible let's go for it, it's way more efficient than the combo loads/dumps
• I don't get why redefining a method should slow down anything (reseting the FileInput need to be done with caution if you want to be able to reuse it). I would have put my money on the loads/dumps combo.
• I agree with your thought about the binding. that's why I would advocate to create a generic sepal_ui.Model (and make aoi_model class inherit from it) object to directly bind stuff; export and import. I still don't know if we should use traitlets or members. problem with traitlets being that people will surely not understand how to use them. What would you think ?
• which csv do you want to transform into pickle ?

[12rambau]

Ok I confirm that Dict object cannot be observed (as List) quote: ipython/traitlets#495
I'll try to find an elegant workaround (it's clearly this that was reducing the loading speed)

[12rambau]

ok I've pushed everything I wanted to modify:

• update some bugs in the LoadTable and vectorField
• create a Model object that use dlink for bindings (as they are traitlets you can still use link if you prefer (I think the bind method with only 2 params will be easier to get for the users). I used dlink because sometime multiple widgets are linked to hydrate the same trait (admin levels for example).
• Reset debug to Falseto actually see the messages in the alert
• I like the way it works now 😄