Mridul, I have some ideas on how to architect the mapping features. I'm interested in how we might break it out into a general purpose privacy-oriented location choosing interface in JavaScript, and include it into our project that way. Like we've done with the rich editor and inline markdown editor. I'll post some more notes on your proposal later today. Thanks for your interest!

https://github.com/publiclab/PublicLab.Editor

https://github.com/publiclab/inline-markdown-editor

This also allows us to make clearer test suites for how the system should behave. And maybe recruit contributors from other projects who need this functionality in their own work.

This is a really exciting project idea!

Hi, Mridul - it sounds like there are a few distinct features we're hoping to get built. I think one really key one you've been working on a lot could be described as a stand-alone module, perhaps called "blurred-location-form" -- a JavaScript module which is added to (or creates) a Leaflet map and location input just like you've created, and outputs a standardized "blurred" location -- a location rounded to the nearest decimal latitude/longitude.

• based around the Leaflet library
• available on npm
• uses HTML template like PublicLab.Editor
• we could start with an example repository
• behavior tests with Jasmine
• abstract geolocation -- could be done later, but so you could swap Google geolocation for another system
• default "warning texts" to explain the privacy features

Another sub-project might be a plots2 system for finding vague location of any type: person, wiki, note:

• ability to display in a map a collection of nodes.each do |node| on a Leaflet map
• node.isBlurred and node.blurredLocation -- do we display blurred locations, or just full-resolution locations? Could a blurred location be indicated by a region for some zoom levels, and a marker when you zoom out enough?
• unit test "isBlurred"
• determine how blurred locations are stored, as floats, strings, etc
• test display of location, vague location

This is a start, but could be fleshed out even further. I'd love to see a test-driven approach to these modules. Does this kind of breaking-out into modules make sense to you?

Is this a question? Click here to post it to the Questions page.

Yeah this makes complete sense. Could you tell me some places where I can find more information on such things?

Is this a question? Click here to post it to the Questions page.

Yes, actually if you wanted to try to install an external module like https://github.com/publiclab/PublicLab.Editor/ or https://github.com/publiclab/inline-markdown-editor and try building them and familiarizing yourself with:

1. how to build the source
2. how testing works
3. how they integrate with plots2

that would be a great start. Then you might consider building a static version of your work to date in a folder, as in the examples on the above projects -- and getting your code from plots2 running on those static page examples. What do you think?

Of course you can also just plan out these steps as part of your proposal, before doing them.

Is this a question? Click here to post it to the Questions page.

Hi, Mridul - i was also thinking about how, if we standardize the way of storing the location information, we could then (to some degree) separate the code for displaying locations from that of selecting locations. Some code might be shared, like the grid display code. But other code might be quite separate -- maybe not a completely separate library, but at least written and stored separately. Maybe that's a good way to think about the two different lists of features I wrote above.

Have you had a chance to try downloading and "building" one of the modules I mentioned above? I'd love to accept a pull request for one of them if you want to give it a try.

Is this a question? Click here to post it to the Questions page.

@warren Yes I have downloaded and built PublicLab Editor and was understanding the source code. I think I should start building a new repo regarding only location section as done in PublicLab Editor. What do you suggest? I have also updated my proposal, can you please review.

Is this a question? Click here to post it to the Questions page.

That sounds like a good next step, great! You can copy in your existing map code as closely as possible and try to "build" it using grunt and, perhaps, browserify. Take a close look at how this is done in the two examples I sent; they're each a little different but will be helpful examples. Do you see how require() methods work to combine multiple pieces of code?

Also, see how we might develop an abstract function instead of a use-specific one, here:

Week 3 (6 June - 12 June): Add privacy options and option to remove location from profile.

Instead of doing this just for a profile, we could make a generic method for selecting a privacy-blurred location, as you've mostly done already. Then, this step would be integrating this into the back-end system for storing such a location. Make sense?

Is this a question? Click here to post it to the Questions page.

@warren Got it. Will start with the new repo right now, any feedback on the proposal?

Is this a question? Click here to post it to the Questions page.

@warren Started with the repo will work on it side by side. (https://github.com/mridulnagpal/map_module)

A-MA-ZING!

@xose Thanks alot. Any feedback on the proposal ?

Is this a question? Click here to post it to the Questions page.

Hi, @mridulnagpal -- great work, let me think of some things that'd help start getting this together:

• If you make a branch called gh-pages, you can try it out online in GitHub, kind of like how we've done here: https://publiclab.github.io/inline-markdown-editor/examples/
• I think a good README would be great, similarly to the other example modules, that shows exactly how to instantiate your code
• The example HTML file could include comments showing the <!-- START OF EXAMPLE --> and the end -- so people know what's strictly necessary.

I think a name might do well to include leaflet -- what do you think about leaflet-blurred-location?

How are you thinking of doing Jasmine testing? I often start just with an empty test suite that asserts true just to see that it properly runs. And then I put the documentation on how to run tests in the README. You can just copy a lot of the README from the other example modules I've linked to as you begin to add those functions.

This is looking great -- once we iterate a bit, we can make it under the Public Lab account, and have that be the "main" repository. Thanks for your hard work on this!

Is this a question? Click here to post it to the Questions page.

Superb https://mridulnagpal.github.io/leaflet-blurred-location/examples/ Adding a README and starting with the test integration as well. Thanks :)

Hi @mridulnagpal Sorry for neatpicking but I saw you mentioned "using Drupal" at some places like

Week 3 (6 June - 12 June): Integrating map features such as privacy options, removing maps to the backend using ruby controllers and Drupal.

Week 7 (4 July - 10 July): Adding external information such as gear required, organizers, etc. to any event notes' map (By using Drupal to add location to the notes).

Drupal is a different framework and isn't used in plots2. Perhaps you tried to convey something else?

Is this a question? Click here to post it to the Questions page.

@ananyo2012 Oh I did not know about that I meant integrating it to backend using the node system we use. Thanks for the heads up :)

Hi, @mridulnagpal! I've looked through your plan in detail and wanted to propose some revisions and a way to break up the work into phases a bit more. I've posted my thoughts over in a new repository named as yours is -- but under the publiclab name:

https://github.com/publiclab/leaflet-blurred-location/issues/1

Some things we'd like to de-prioritize, and others we'd like to do in a different order. Would you mind taking a look and telling me what you think? I hope it makes sense and I'm happy to help flesh it out further.

Is this a question? Click here to post it to the Questions page.