discussion on the content of this repository

[12rambau]

Tagging relevant individuals for distribution: @giswqs, @jdbcode, @fitoprincipe, @gena, @dfguerrerom.

Following discussions with both @giswqs and @jdbcode during G4G, I propose an initiative to extract the essential ipywidgets-based interactions from geemap and house them in a separate repository. This proposal stems from the current scenario where anyone intending to create a new library based on the Map object is faced with the dilemma of either rewriting all key functions from scratch (e.g., addLayer, centerObject) or resetting the map during instantiation. An illustrative case is found in sepal-ui, where we follow this approach.

There is also a secondary use case where someone may require only a Map or a specific key widget rather than the complete geemap package.

Planned Actions:

• Leverage the earthengine-api and gee_tools for static computations (note that gee_tools will soon incorporate matplotlib outputs using the same data as any interactive plotting library).
• Extract essential functions from geemap.
• Extract crucial functions from sepal-ui.
• Extract essential functions from the original ipygee.

I was thinking about the following structure (all being available directly from ipygee:

Ipygee/
├── map/
│   ├── map
│   └── valueInspector (a map control)
├── widgets/
│   ├── asset_selector (structured as an folder crawling system, extracted from sepal-ui) 
│   ├── dataset_crawler (structured as a search field from geemap) 
│   └── task_manager (a rich widget from original ipygee)
└── plot/
    └── as many plots as we see fit (I have a crush on bokeh but any can work)

A quick note for @fitoprincipe : I've made an earnest effort to adapt the original ipygee code, but it's proving to be an exceedingly labor-intensive task. Do you concur with the idea of moving forward with this new repository, which will be linked to my 'copier' pypackage? Regardless of what portions I borrow from your code, I'll manually credit you as a contributor in the commits for proper acknowledgment.

I'm eager to hear your thoughts on this, and please do inform me if you believe more individuals should join this discussion.

[giswqs]

The geemap.core module is lightweight version of geemap. What do you mean by rewriting addLayer and centerObject functions? We can easily make them available in the core module as well.

https://github.com/gee-community/geemap/blob/master/geemap/core.py

[12rambau]

sure I meant that at the moment when you load the geemap.Map object you cannot get a dry version (like the vanilla ipyleaflet.Map, all the widgets are on the map. It makes sense for geemap as it's aiming toward nearly no-code interaction with the data but for other applications (when one builds its own custom set of widget controls for example) it would be easier to only load a controlless map with only the methods don't you think ?

[giswqs]

All widgets on the map are customizable. They can be toggled off during map initialization. Like this:

m = geemap.Map(data_ctrl=False, toolbar_ctrl=False, draw_ctrl=False)

[giswqs]

Or geemap.Map(lite_mode=True), which only contains the zoom control.

[12rambau]

I didn't know about the lite mode which is exactly what I expected: "opt-in" the controls I want to see instead of the original "opt-out"

[giswqs]

Or using the core module, which is very minimal. Try it out and let me know what widgets you want or don't want on the map. We should be able to make those customizable and be toggled on/off easily. In general, we should avoid duplicating the work. That would make more work for you to maintain the package

import geemap.core as geemap m = geemap.Map()

[12rambau]

to me the minimal version should look like a vanilla ipyleaflet (only the zoom and copyright controls)

[giswqs]

Correct. The core module is co-developed and maintained by the GEE team. Additional widgets and be added as needed. Users can build upon the core without duplicating the essential features, making it easier to maintain

[giswqs]

You can propose in the geemap repo to allow opt-in controls. It should be relatively easy to implement

[12rambau]

But my point was to externalize it here outside from geemap to lighten your (😄) burden:

• smaller code-base
• smaller and more dedicated test suits
• lighter subpackage to build extra-tool on top of it, geemap being the flagship
• reintroduce chore functionalities from other packages to avoid reinventing the wheel (ipygee, sepal-ui, eemont)

similar to what ipyvue is to ipyvuetify or traitlets for ipywidgets. You never import it yourself, only the chore developers know it exists but it makes code base easier to maintain.

Instead of having ipygee depending on geemap I was more thinking to have geemap depend on ipygee. I was even thinking having something like this in the documentation: "ipygee include chore widgets dedicated to GEE. It's intended for advanced Python developer. For a completely integrated map based interface please use the amazing geemap" (TBD)

[giswqs]

Understood, but I think it would be better to have a single minimal version for map widget rather than duplicating the work. The geemap.core is designed for that. Geemap can't depend on ipygee if ipygee has its own map widget because geemap can't utilize it

[12rambau]

why cound't you depend on ipygee if it's a transfer of geemap.core ? (that's what I meant by extraction)

[giswqs]

The geemap Map class depends on the geemap.core Map class. Keep in mind that the core module also depends on several other modules in geemap. Of course, you can duplicate all those modules in ipygee, but they will just create extra work for you to keep synced with those in geemap.

If ipygee has its own Map class, that means geemap's Map class can't utilize it. Of course, geemap can still utilize other non-map functionality in ipygee.

If both geemap and ipygee have their own map widgets, then users will have to choose either the geemap map or ipygee map.

[12rambau]

Ok got it, I need to dive deeper in the core module to better understand how intricate it is with geemap itself. In the meantime can I start working on the task manager and the asset crawler ?

[giswqs]

Sure. These are great features. Looking forward to it