Revamp LEL Architecture .

[sagarpreet-chadha]

The current architecture is that we have one file for each Layer which is working fine but seems not very scalable as there is redundancy of code in each layer file .

Let's brainstorm here on how to improve this ? I would like to have ideas from everyone especially @sashadev-sky and @jywarren and @ananyaarun 😄 .

To Do's :

• [ ] Write Tests (High priority) --- Should we continue with Jasmine or shift to another testing framework .

• [ ] We have to soon integrate LBLD to plots2 . I think we should not merge any of our Leaflet projects and keep them independent as it becomes easy to track bug if any . Let's integrate LBLD directly to plots2 and mapknitter AND not via LEL , makes sense ? What do you all think ?

• [ ] Brainstorm on standardizing Layer code .

• [ ] Write a detailed documentation for first timers to add new layers easily . Then let's create first timer issues of currently opened issues .

What more ?

[ananyaarun]

@sagarpreet-chadha , I think this issue has a few more points in this regard https://github.com/publiclab/leaflet-environmental-layers/issues/134. After feedback from @sashadev-sky and @jywarren , we can come up with a list of features and changes that can be implemented during the summer :)

[sagarpreet-chadha]

Agreed @ananyaarun 😄 ! Congratulations on getting selected for Outreachy 🎉 . Actually i wanted to discuss here some of those points from #134 (i kind of aggregated some of those issues here) . I would love to discuss with you here , you can mention some details from your proposal here as well . Thanks 🎈

[ananyaarun]

Thanks @sagarpreet-chadha :smiley: !!

This can serve as the planning issue for the outreachy project. According to me the goals of this project can broadly be classified into these issues/improvements

1) Layer display and UI based issues

• color coding of layers
• improve structure in the layer selection bar
• demarcation between layer types (group similar ones under a category etc)
• add meaningful names to base layers
• zoom and bounding box handling

2) Standardizing Layer code

• find similarities in code btw layers
• remove redundant code and pass layer type as parameter to a standard layer display code (common function which could be used to reduce redundant code in layers)
• refactoring based on common functions

3) Documentation

• create a template for layer addition
• document layer addition process
• create FTO's for adding new layers after improving documentation

4) Testing

• decide on testing framework (jasmine or other)
• write tests
• connect the test to TravisCI using a .travis.yml file

We can use the next few days to finalize the goals , and I'll look through the previous issues in this regard and my proposal to get more clarity of what can be done and keep updating this list :) .

[sagarpreet-chadha]

Awesome !!!

[sashadev-sky]

Hi @sagarpreet-chadha Im sorry i'm a little behind with this repository but I am planning on catching up this week! My first question is what does LBLD stand for? I can't find a reference to that acronym

[sagarpreet-chadha]

Hi @sashadev-sky , no problem . LBLD is another project in Public Lab : https://github.com/publiclab/leaflet-blurred-location-display . Thanks :+1: !

[jywarren]

Hi, all! This is great. I wanted to chime in with some ideas! One is, that we could generally follow a MVC model/viewer/controller approach, although it wouldn't map perfectly... so, maybe a variant of this idea. @Rishabh570 has been working on MVC for https://github.com/publiclab/community-toolbox, and may have some useful input to help you guide your code structure, as might @IshaGupta18 and @namangupta01 who are architecting a new CSV graphing library at https://github.com/publiclab/simple-data-grapher/. @sidntrivedi012 will also be creating a new library for the Spectral Workbench Capture project and may want to listen in.

The categories could be:

• Interfaces
  • Default Leaflet-style control with list of layers (currently used)
  • the bigger "menu" shown below, which has checkboxes and more info for each layer
  • a button-based switcher as shown in the second image below
• Switcher:
• Layer modules
  • each layer would have a standard set of methods like:
    • layer.show()
    • layer.hide()
    • layer.isVisible()
    • layer.isInRect(lat1, lon1, lat2, lon2)
• Generalized layer types to make adding new layers easier; these could be "included" into new layers to automate layer functions for really standard types.
• Standard methods for showing popups when you click on layer content?

I'm thinking maybe a diagram could help with all this, sort of like in the README for https://github.com/publiclab/image-sequencer/

This is my attempt, although it's really not good! Quite messy and conceptually a bit... confusing.

(document: https://docs.google.com/presentation/d/18EQdwoU_PLJ0abMqWjDgx0Wc_r77LfZnd7bjMFcmkaQ/edit#slide=id.g578b8d8abd_0_27)

Maybe some of you want to give it a try yourself? Just make a copy of the diagram and try your own. @sidntrivedi012 @IshaGupta18 @namangupta01 feel free to make your own although some of you already have (feel free to link to your proposals!)

OK, this is a lot of ideas. I'd love to see what direction you go with them!

Here are a few ideas on the different "menus" for choosing what layers to show:

I've made a few more variations as well. I think planning to offer a few different ways to use layers could be powerful. They could be instances of the Leaflet.Control class, maybe? And, perhaps the planning of these menu types and the design could be broken into its own issue!

[ananyaarun]

Thank you so much @jywarren !! . Those are some really good points to take note of. :smiley:

[ananyaarun]

Also @sagarpreet-chadha , shall i open a new issue for outreachy project planning after taking points from this discussion , as i cannot edit the present checklist ?

[sagarpreet-chadha]

Yes please go ahead :)

[jywarren]

Hi, all! I wanted to introduce @rarrunategu1, who's starting some work with us at the Providence office, and who I was hoping could pitch in on a few issues as well. While the architecture and structure of the library progresses, I was hoping @rarrunategu1 could try working up a static HTML mockup of the new "table" menu in this comment above, and putting it into a folder like /templates/ for later use. Shall we open up a new issue for that specific menu type?

[sagarpreet-chadha]

Hi @rarrunategu1 :smile: , Welcome to the community :)