SPIKE: Draft json spec for EcoMap configuration

[atmorling]

What about something like:

{
    "initialViewState": {
        "longitude": -1.415,
        "latitude": 52.232
    },
    "basemap": "OpenStreeMap",
    "ee_layer": {
        "@data": "ee_image",
        "vis_params": {"min": 0, "max": 4000, "opacity": 0.5, "palette": ["006633", "E5FFCC", "662A00", "D8D8D8", "F5F5F5"]}
    },
    "gdf_layer": {
        "@data": "sightings_gdf",
        "fill_color": {
            "column": "groupby_col",
            "values": {
                "Category1": [70, 107, 159],
                "Category2": [209, 222, 248]
            }
        },
        "radius": {
            "column": "SimpleCount"
        },
            "zoom": true
    },
    "title_widget": {
        "title": "Elephant Sightings"
    },
    "compass_widget": {
        "position": "top-right",
        "style": "svg/url"
    }
}

Such that the python would be:

ee_image = ee.Image("USGS/SRTMGL1_003")updateMask(dem.gt(0))
region_gdf = pd.read_csv("sightings.csv")
EcoMap(spec, ee_image=ee_image, sightings_gdf=sightings_gdf)

• In general the idea is that we'd have sensible defaults that the JSON could override in as much detail as needed, however, one needs some amount of detail in the layer definitions as you need to know what you're colouring, is it a line or a poly fill or a point, etc.
• gdf_layerin this case is intended to represent point data. We could make it more explicit by replacing gdf_layer with scatterplot_layer, but the type can be inferred from the data supplied.
• "@" properties refer to an equivalent Python kwarg passed to the map constructor, this could apply to more than just what's shown in example ie; @vis_params or @values

[atmorling]

Also note: Our notion of a "Basemap" is derived from Leafmap's basemaps module, which is effectively a collection of common WMS/XYZ tileservers, where the "Basemap" is just the first tile layer added to the map. This is distinct from the deck.gl "Basemap" which is map client like MapLibre or OpenLayers used as a base for deck.gl to overlay on top of. For our purposes the Leafmap way of thinking makes more sense and this conflicts a little with Lonboard's implementation. I don't see any roadblocks for us right now, but this is something to pay attention to.

[walljcg]

This looks good! Is this json spec based on anything specific or a combination of different things? A few points from my side: the order of the layers in the json should define their order when drawn on the map. We should also be able to handle multiple of everything, e.g., multiple gdfs, ee layers etc. I'd probably rename 'InitialViewState' to 'ViewState'. I don't love the 'basemap' naming convention because it's really just a tiled raster layer that happens to be at the bottom. I think let's just call it 'tiled_raster' and then we can also have 'tiled_vector' layer. We should look at supporting WFS services as well.