Hi everyone ,

I would like to take input from the community to give suggestions on how we can improve the use of Leaflet-environmental-layers and Leaflet-blurred-location (which will be soon live on plots2) library .

I would like to work on these inputs in the coming summer.

Thank you 😃 !

Hi, Sagarpreet, thank you!

You've done some great work on various Leaflet libraries and I love it. For this proposal, I wanted to suggest that you place extra emphasis on a few things:

1. thinking about the architecture of the libraries to reduce redundancy, for example to make it relatively few lines to add new layers to LEL. See for example the Image Sequencer contribution section - could a lot of the layer setup be standardized and excerpted into a new layer adder submodule like addLayer or something? Things like that which make the libraries extensible and readable.
2. community building - i think there's a big potential for a library that accepts self-contained standard module contributions (like Image Sequencer's Modules) to build a community, because each contributor can focus on submitting one standard module, instead of having to worry about the whole system. Make sense?
3. testing and bugfixing -- I think LEL in particular starts to need testing to remain reliable. This will also help to "protect" well-functioning systems against future bug introduction.
4. LEL especially has been a great proof of concept, and now needs some restructuring and formalization to reach it's full potential! https://github.com/publiclab/leaflet-environmental-layers/issues/134 covers some of this, and in particular, separation of UI code (like building and driving the checklist menu vs. other ways of displaying the layers) from the core functionality using standard functions and maybe an event/listener model
5. Maybe a JSON-based standard way to store the metadata for each layer? https://github.com/publiclab/image-sequencer/blob/main/src/modules/Rotate/info.json

Thank you!!!

Problem #1 : Architecture Problem

Currently the code has a lot of redundant code , Most of the layers have the same code in their JS files . When we add new layer , we are using the same code again with minor changes in the code like changing sourceURL , markersURL and the API_parsing function . Although the architecture is good as of now , but it is not scalable and maintainable .

Solution #1 : Using One-for-All Architecture

Let’s make a generic common module which would be fully tested having all the functions implemented to add new layer . This module will be very flexible and existing layers like : Mapknitter Layer SkyTruth Layer Fractracker Layer PurpleLayer Layer Toxic Layer will be implemented by :

The architecture would be similar to that of PL.Editor where we have a generic module and all other modules are implementing that module . Also the new architecture will make sure that any new contributor while working on new layer will have to work on one single file only and not take care of the entire system . —> Advantage : 1.) Maintainable 2.) Easy to review new layers 3.) Easily Testable 4.) Less lines of code

Problem #2 : Personal User-defined Layer

Although we have many amazing dynamic layers implemented , but their API URL is fixed . Many people on Stackoverflow and Github have asked how to add custom layers . Currently there is no library which allows users to add their own custom layer .

Solution #2 : Add Custom Layer module

We have already implemented similar feature in LBLD to add custom API with custom parsing function .

Problem #3 : Lack of Contributors

Currently there are a very few people working on LEL .

Solution #3 : Let’s build a community !

I feel LEL has the potential to welcome many new first-time contributors . Let's make the documentation of how to add a new layer so easy and well structured that a new contributor can start work immediately . I will be working on making new well-defined first-timer-only issues during the course of the summer , describing each step of the process concisely . Also let’s complete this checklist on Github :

Problem #4 : Segregate UI code

Currently all the UI code is in the index.html . Also we have not provided any provision to add Layers button on the map in the library . To add the Layers button , one needs to understand additional code .

Solution #4 : Build UI module

Let’s make a provision in the library to automatically give the end user the layers button . I will implement a UI module for this purpose with function :

Problem #5 : Testing

We do not have any tests yet . I will be focussing majorly on testing the generic module first and then UI module part . Then moving on to testing individual layers . Also after implementations of this new tests , we can request first-timer contributors to write tests as well when they implement new layer module .

Hi Sagarpreet - just noting that there was an issue possibly related to a revision on this node, and I changed the vid of the node's latest revision. I believe everything is as it was, but if you notice anything wrong please bring it to my attention. Thanks!

And thank you for your detailed response; i'll be reviewing Monday i hope! Looking great!

I think when i was updating my proposal , there was some error displayed "to correct bold heading , use * correctly , etc. " , but i clicked the submit button regardless and then the spinner kept loading without sending request to server .

Now i am again not able to update my proposal .

Update : I am able to change the main image but not able to update content .

This is awesome Sagar. Please include some time for reviews, ftos and blogs in the timeline. Also it will be great if you can guide other contributors in their proposals. Thank you Sagar

oh no, Sagarpreet, can you open an issue for this? I think i saw an issue opened https://github.com/publiclab/PublicLab.Editor/issues/306 maybe it's the same one?

On Sun, Mar 17, 2019 at 3:29 AM \<notifications@publiclab.org> wrote:

Hi! There's been a response to a discussion you're involved in. You can reply to this email or visit this link:

https://publiclab.org/notes/sagarpreet/03-09-2019/gsoc-proposal-lel-2-0-and-work-on-leaflet-blurred-projects#c22176

sagarpreet wrote:

---

I think when i was updating my proposal , there was some error displayed "to correct bold heading , use * correctly , etc. " , but i clicked the submit button regardless and then the spinner kept loading without sending request to server . Now i am again not able to update my proposal .

---

Look like spam? Mark this as Spam

Reply at: https://publiclab.org/notes/sagarpreet/03-09-2019/gsoc-proposal-lel-2-0-and-work-on-leaflet-blurred-projects#comments

Report abuse to: moderators@publiclab.org

Check out the blog at https://publiclab.org/blog | Love our work? Become a Public Lab Sustaining Member today at https://publiclab.org/donate If this email title has an ID in the format #0000, you can reply with the email you use at PublicLab.org and your response will be posted as a comment on the website.

Hey @warren ,

This is the link to my full proposal , kindly review it once :)

https://drive.google.com/file/d/1G_1JMFQmyrZhDnrvpXSNZjvEUWVk0R-t/view?usp=sharing

Hi @warren , @guaravano , @liz , @stevie ,

I have updated my proposal 😃 ! Kindly review 😇 .

Hi @sagarpreet, thank you! Are you now able to edit your proposal on PL.org again? Sorry i should have followed up more on that.

Overall i LOVE your plan for re-architecting. I love the idea of there being a parser component.

I feel LEL has the potential to welcome many new first-time contributors . Let's make the documentation of how to add a new layer so easy and well structured that a new contributor can start work immediately .

This is so true, and we can see how in image-sequencer the 'module' concept caught on so fast -- people only have to know (with good docs) how to make a module, and they can make a really substantive contribution to the library. Critical to this was making the format of each module really standard, and also easy! Few steps.

Another thing I'm really looking forward to is the idea of multiple swappable UIs. The current menu UI can see some improvements like organizing by type. But the bigger UI described in https://github.com/publiclab/leaflet-environmental-layers/issues/60#issuecomment-460462757 is something we could even run in parallel at the same time. And with the right listeners, callbacks, and documentation, people may even build more different UIs for LEL. This is a big part of the project too.

However, I think it's possible that we may have more than one person working on LEL this summer! So, although I'd love to hear a little of your ideas for how the UI interfaces with the core library, implementing the bigger UI I linked to doesn't have to be a major part of your proposal necessarily.

Thanks a lot @sagarpreet! This library has grown so much and it's time to think bigger, and your additions and plans above make for a great roadmap! 😃

Hi, please upload your proposal at the Google Summer of Code website at the earliest. Please ignore this comment if already done.