Question: Representing contextual layers legends in the database

[agnessa]

I believe we now want to store the list of contextual layers in the database, at least that's what I understand is implied here.

While most of the attributes from this json can be used verbatim as database columns, I struggle to break down the legend property into a representation that would allow the frontend to generate the html, as storing html in the database is not a great option. So far I managed to isolate these properties that seem relevant:

legend_type (e.g. custom, choropleth) legend_colours - array of hex colours legend_labels - array of labels

Would that be enough to generate the legend? I notice that sometimes the <li> element has a bkg class and sometimes not; I'm not sure why that is but if it is important, how best to represent it?

One more question: forceZoom is so far undefined for all, will it be used in the future or can it be left out? Is this meant to be an integer or boolean?

[nerik]

I don't think the BC issue is about context layers. It's about the choropleth layers (data served by get_nodes), and if looking at the issue I'm not sure what are the next steps to be taken.

As for context layers:

• there's more to it than the file you pointed to. This file is generated offline by a script that uses the CARTO API, using this file as the source of data (which results in those layergroupids values)
• storing the html for the legend is a hack/convenience. It is certainly not ideal, but let's evaluate if it's worth using a complex data structure now.
• forceZoom is legacy since we removed the Silos context layer.
• overall, I'm not sure context layers should move to the DB right now, maybe a simple context - context layer ids association would already be a start.

[nerik]

(maybe @tiagojsag can disambiguate)

[nerik]

(corrected a missing link in the original message)

[agnessa]

I might have linked to the wrong BC task, the description in this one is very vague; but Tiago did mention to me representing the contextual layers in the db, and the fact that we might have a different layer source for different years. I hope he can clarify, especially about the layergroupids.

[nerik]

Worth precising that the call to the CARTO API whenever we want to change or add a context layer is not avoidable. We could go through the pain of moving this to the backend, as well as the legend data structure we discussed, but I'm not sure it's ideal.

[agnessa]

Fair enough. So for the time being I'll assume we only want to store the links between contexts + years + layer ids. Are the layer ids the textual identifiers under name in the json? Could I assume that e.g. when we have another contextual layer for Brazil protected areas for different years, it would need to have a different name != brazil_protected?

[agnessa]

Or even more broadly, should that name be unique across contexts?

[nerik]

It's never a question we had to ask ourselves as there were only context layers for Brazil, not dependant on the year selected.

So for the time being I'll assume we only want to store the links between contexts + years + layer ids. Are the layer ids the textual identifiers under name in the json? Could I assume that e.g. when we have another contextual layer for Brazil protected areas for different years, it would need to have a different name != brazil_protected?

Yes to all of that.

[tiagojsag]

Ok, a few things we will have:

• Contextual layers (the ones from carto) for different country/commodities
• Within the same context, contextual layers have year limits. e.g. land cover is only available for 2014 and 2015, but not 2013.
• Within the same context, contextual layers different version per year. e.g. land cover shows different data for 2015 and 2014
• We will have tooltips for these
• We don't want the actual data to come through our API. Simple use case, we store the carto URL on the db, pass that to the FE, that then loads that data

[nerik]

• heed the case where a context layer is the same for all years
• let's just have the DB store only unique id strings as explained by Agnieszka. Handling CARTO calls (including generating the URLs) is a concern for the front-end.

[agnessa]

Where we return year-specific data we have two choices on how to handle "all years" - either a null to denote all, or a list of all years. What's better for FE @nerik ?

[nerik]

Here's a proposal for a JSON mock (for a given country-commodity context). I hope it'll help.

context_layers: [
{
  is_default: true,
  title: 'Brazil biomes',
  id: 'brazil_biomes',
  tooltip: 'Brazil biomes lorem ipsum blabla',
  carto_layers: [
     { id: 'brazil_biomes', year_span: null }
  ]
},
{
  title: 'Land cover',
  id: 'landcover',
  tooltip: 'Land cover lorem ipsum blabla',
  carto_layers: [
     { id: 'landcover_2015', year_span: [2015] },
     { id: 'landcover_2014', year_span: [2014] }
 ]
},
{
  title: 'Water scarcity',
  id: 'water',
  tooltip: 'Water scarcity lorem ipsum blabla',
  carto_layers: [
     { id: 'water_2014_2015', year_span: [2014, 2015] }
 ]
}
]

This should cover the 3 use cases I can think of:

• context layer independent from year selection
• context layer that changes depending on the year selection
• context layer that doesn't change depending on the year selection, but is restricted to a year span

[tiagojsag]

• missing "tooltip"
• missing isDefault (currently is part of the get_contexts, but makes more sense to move it here)
• 'years' object key is a bit misleading, although I can't come up with a better alternative, and I'm happy to keep it if no one else has another suggestion

[nerik]

Thanks, for the comment, amended the original comment. carto_layers might be better than years, as it represents what it actually is in the end result.

[tiagojsag]

looks good. Just a couple of heads up:

• you will always get a isDefault value, true or false.
• the root element probably should be named "data" to match every other API call we have.

[nerik]

you will always get a isDefault value, true or false.

no problem

the root element probably should be named "data" to match every other API call we have.

I was not aware that would be on a separated endpoint, but ok, fine. I guess this endpoint will take a context id as parameter.

Also, I realised an id was also needed on each object of the array, so I added that to the mock.

[tiagojsag]

ah, you want to load this in the get_contexts? yeah, makes sense, I just assumed it would be a separate call, for no good reason, now that I think about it

[tiagojsag]

"moved" to the new repo, closing