User:Umang2705/GSOC-14/Proposal

From WikiEducator
Jump to: navigation, search

Personal Info

Name:Umang Goel
Project:Mapping
Academic Background: I am a second year student studying at International Institute of Information and Technology, Hyderabad, India pursuing BTech in Computer Science and Engineering.
Location:My hometown is in Uttar Pradesh and I study in Hyderabad,India.
Timezone: IST (UTC +5:30)
Working Hours: My working hours are very flexible. I could easily work anytime between 5:00-00:00 UTC (10:30 - 5:30 IST) including weekends.I can easily work for 40-45 hours per week. But if project demands spending more time on it, I would be up for it.
[Github Account]
Link to wikipage : wikieducator.org/User:Umang2705/GSOC-14/Proposal

Contact Info

Email: umang.goel.in@gmail.com
IRC nick: umang (freenode)
WikiEducator username: umang2705

Goals/Output

Goal

  • Main goal of the project is to implement map widget using Leaflet.
  • Improve authoring convenience for adding pushpins.
  • Pull locations from wiki table.
  • Make provision for translating the text.
  • Make an android application for using/accessing maps.
  • Allow user to export data map.
  • Allow user to export static map image as pdf.

Output

The following would be the set of deliverables available after the project completion :

  • Provide a map widget which uses leaflet for rendering maps.
  • User would be able to add pushpins by clicking on the map. While adding pushpins the user could also add image and text to it.
  • User can continue to add pushpins by specifying the lat/long.
  • User can also provide a file using which the pushpins can be added.
  • Make functionality to allow user to translate the text that appears on the map.
  • An android app which the user could use to view and edit maps.
  • User can export the pushpins information as pdf (will include images).
  • User can export the pushpins info as a text file (will not include images).
  • User can save a the static map as a pdf.
  • User can edit the existing pushpins just with some click.

Implementation Details

Basic WorkFlow/Steps

Steps for displaying map:

  1. Using wikimedia REST api a http request to receive the data would be sent.
  2. The recieved string would be parsed (using a json parse) to extract zoom level, center point, flags etc.
  3. Leaflet apis would be used to display the map.

Steps for adding pushpins:

  1. For adding a pushpin user need to click at that location.
  2. Choice for user to enter text and enter image would be displayed.Button to add pushpin and cancel would be shown.
  3. Pushpin would be added if user presses add button.
    • Note: User need to login before adding pushpin.

Working at backend :

  1. When user click on a location the coordinates of that location would be fetched.
  2. Visibility of the textbox and image box would be set true.
  3. After pressing the add button:
    • If the user is logged in :
      1. Using the wikimedia apis a token would be made.
      2. The data (lat,long,text,img) would be added to the table.
      3. Then using the wikimedia REST api a http request to add the table would be sent.
    • If user is not logged in :
      1. The process would be terminated.
      2. Display message to login would be displayed.

Adding pushpins manually :

  1. There would be two text boxes present in which the user could give the lat/long.
  2. If user pressed add pushpins button.
    • If user is not logged in the pushpin wouldn't be added.
    • Else pushpin would be added.
  3. Then the added pushpin would be selected an option for adding text and image would be visible.
  4. The user can then add text and image and save the changes.

Adding pushpin from the file:

  1. The user should enter the path to file. The format of the file and the data present inside it would be fixed. The user would have liberty of adding json,csv or xml file. The format would be lat,long,text,img (path-to-url or path-to-directory). The img tag would be optional.
  2. Upon clicking add the file would be read and parsed.
  3. The extracted data would be stored in an array.
  4. All the data from the array would be saved to the wiki account using the mediawiki apis.
  5. The data present would be updated and the updated pushpin would be displayed on the map.

Steps for Deleting pushpins:

  1. The user need to double click on the pushpin.
  2. A button to delete the pushpin would appear.
  3. If user clicks on that button a warning popup would be generated.If user click on ok, the pushpin would be deleted.
    • Note: The user need to login before deleting.

Working at backend :

  1. Identify the pushpin from the coordinates of the clicked location.
  2. After pressing delete button:
    • If user is logged in:
      1. Using the wikimedia apis a token would be made.
      2. New table would be created that would not include data about the clicked pushpin.
      3. Then using the wikimedia REST api a http request to add the table would be sent.
    • If user is not logged in :
      1. The process would be terminated.
      2. Display message to login would be displayed.

WorkFlow for saving map :

  1. There would be a button available which would be clicked to save the map. The user uneed not be logged in to use this feature.
  2. Upon clicking the button their would be a popup for saving the pdf file. If user clicks ok then the pdf would be downloaded.
  3. Internally a function would be called that would use leaflet.print plugin.

WorkFlow for saving pushpins info:

  1. There would be button to save the data regarding pushpins.
  2. Upon clicking the button there would be two choices available.
    • Save as pdf.
    • Save as text.
  3. If user chooses save as pdf then all info including images would be saved.
In the backend a function would be called that would use jsPDF api to save data as pdf. All the data regarding pushpins would already be stored in some arrays (used already to show pushpins on map).
  1. If the user chooses save as text then images would not be saved.In this case the user need to give the path where the file is to be saved.
In the backend a function would be called that would use CreateObject and CreateTextFile javascript methods to save data as text. All the data regarding pushpins would already be stored in some arrays (used already to show pushpins on map).

Workflow involved in translation :

  1. The user need to select the go for translation option. The button would be in a form of an image (it would be predictable).
  2. The user need to enter the target language (the final language in which the text should be converted).
  3. The user would see every text translated in the target language.

Backend Process :
The core thing involved in translation is making an appropriate http request which would be sent and the response would contain the translated text. YQL is used for sending the http request. The http request would contain the url of google-translation sevice. Then request has following parameters :

  • q : It would contain the string which is to be converted.
  • des : It would contain the target language. There are particular symbol for each target language which is required to be given. ex: en is given for english
  • format : It would contain the output format of the response. In our case it would be json.
  • url : It would contain the url of the google translation service.

So the following steps would take place when user hits on translate button:

  1. Iterate over all the text tagged with the pushpins.It would already be stored in an array, so we need to traverse that array.
  2. Each of the text would be passed as the value of parameter q and a http request would be sent.
  3. The response would be a json file which would be parsed to extract the translated string.
  4. Each of this translated string would be stored in an output array.
  5. This output array would be used for displaying the text tagged with each of the pushpin on the map.

API Details

Mediawiki REST apis :

  • For logging in :
api.php?action=login&lgname=Bob&lgpassword=secret : It is the first request that it to be sent. It would return a token which would be entered later. The response would be received as a json and need to be parsed to extract the token from it.

api.php?action=login&lgname=Bob&lgpassword=secret&lgtoken=tokenReceived : In this request the extracted token need to be sent.
These would be POST requests.
  • For retrieving data :
api.php?action=query&prop=revisions&rvprop=content&format=xml&titles=Main%20Page : This could be used to get the content of the page. This would again return a json file which need to be parsed to get the response.
  • For editing data :
api.php?action=query&prop=info|revisions&intoken=edit&titles=Main%20Page : This could be used to edit content.
This would be a POST request.

Leaflet APIs :

  • L.map() : It could be used to show map. There are whole lot of options provided to handle zoom,scroll,keyboard events etc.
  • L.marker() : It could be used to add pushpins.We could bind popup with it which would show the image and the text tagged with the pushpin.

Google translation API:
Using YQL we can easily use the google translation api for free. It could be used for translating the text on the map. The YQL http request returns a json string which need to be parsed to get the translated output. Google api provision for auto-detecting the source language. So the user only need to enter the target language. We can specify the output format of the response in the http request which in this case would be json.

jsPDF API:
It will be used for generating pdf. It is a free api whose source code can be downloaded and then used. It can be used by instantiating an object of jsPDF which would provide access to all its functions.

  • <object>.text() : It could be used to add text.
  • <object>.setFont : It would be used to set the text font.
  • <object>.setFontSize() : It could be used to set the size of the text.
  • <object>.setFontType() : It could be used to set the text type (bold/italics).
  • <object>.setTextColor() : It could be used to set the text colour.
The above mention methods could be used for adding pushpin text info.
  • <object>.addImage() : It could be used to add image tagged with pushpin.
  • <object>.save() : It could be used to save the pdf.

Leaflet.Print
This is an additional leaflet plugin available to save the map as pdf/jpg . A sample code code to show the use of api :

	printProvider = L.print.provider({
          capabilities: printConfig,
          method: 'GET',
          dpi: 254,
          outputFormat: 'pdf',
          customParams: {
             mapTitle: 'Print Test',
             comment: 'Testing Leaflet printing'
          }
       });


Mock GUI

It is the link to the GUI : https://docs.google.com/document/d/1WGHDntcUB1UNU66Bs3jk6cW-vFu4TDkf_ynBzJBi9Ig/edit?usp=sharing

Benefits to WikiEducator

The major benefit would be improved user experience.

  • Currently it is a pain adding pushpins to the maps. The user needs to know the lat/long of that place which is really inconvinient for them. As an output of this project users would able able to add pushpins by just clicking on that location.
  • Increasing the usability of the maps. Not all users have their native language as english. By providing options for translation it would even cater to the needs of the local people living anywhere in the world.
  • Increase the accessibility of maps. By providing an android app for accessing the maps, the use of maps would become even more handy.
  • By allowing user to save data it would allow access to data even in the absence of the internet connection.

Long Term Goals and Personal Development

As I'm relatively new to open source, it would help me getting a kick-start. I'm also new to mediaWiki so by doing this project I'll be a lot more comfortable in using its apis. It will also allow me be a part of WikiEducation and would form a base for my contribution. Getting familiar with wikieducation would allow me to contribute to it even after the gsoc period. Another important side of this project is the scope of learning involved with it. Though it might look simple, it involves a lot of work to be done. As I've not being involved with any organization for such a long period of time it would give me insight of how things work in such big organizations and would also give me an incredible experience. It would be like a first step towards becoming an active member of your organization.

Why I'm the best person for this project?

I'm best person for this project because I've a decent experience of working with OpenStreetMaps and leaflet. I've made an android application using javascript, leaflet, jquery mobile and converted using phonegap that allows user to search for and route to locations. It involved adding pushpins and taking choices from user.So I'm already aware of much of the apis and functions which is to be used. I've also researched about the wiki apis that are to be used and I'm quite clear about my implementation plan so if I'm selected for this project I'm confident that I would be able to complete this project within the given time period which will meet the standards of this organization.

Another reason is that I'm a good learner. I could learn things easily. Though I'm slow in the begining, but I'm able to catch up with it. Another reason is the experience. Though I'm new to opensource I've done two project each of duration 1.5-2 months. So I know how things have to be managed in such projects and what problems can arise. One more factor is my dedication. Once I start with a project I never loose my enthusiam to work and I always aim at making a quality product rather than just somehow finishing it. Another important thing for any project is the communication with the mentor. As I've done some relatively long projects in the past, I'm acquainted with the process of providing documents/report of the work done to the mentor on daily basis. So I'll be providing daily/weekly updates to the mentor about the work being done by updating the blog.

Tentative TimeLine

Week Work
Week 1 Decide on final UI by discussing with the mentors. Design test cases ahead of time. Design the application model through UML diagrams. It would give a brief but clear idea of how the implementation would be done. Start with making widget.
Week 2 Make the map widget using leaflet. It would include only displaying the map with pushpins on it. Test it. Get back to mentor for feedback. Incorporate the changes suggested.Update wiki subpage
Week 3 Add functionality of adding pushpins by just clicking allowing user to add text and images along with it. Test it. Update documentation. Update my wiki subpage for mentor to keep track of progress.
Week 4 Allow functionality to translate the text on the map. Test it. Fix bugs (if any). Start making function for adding pushpin from file and manual entry.Update wiki subpage.
Week 5 Finish with both the functions of adding pushpin. Test it. Get it reviewed. Update the wiki subpage.
Midterm Evaluation
Week 6
Refactor the code built so far. Implement anything that is left over. Perform integration testing. Update the documentation. Update wiki subpage. Get the widget reviewed by the mentor. Incorporate any changes suggested. As a result the widget would be ready for midterm Evaluation
Midterm Evaluation
Week 7 Start with the android app. Finish with displaying the map on the screen. Test it. Update the wiki subpage.
Week 8-9 Add login feature. Add functionality of adding pushpins to map. Test it on web. Update wiki subpage. Get it reviewed by the mentor. Incorporate changes.
Week 10 Add functionality of translating the text. Test it on web and android.Get it reviewed by the mentor. Incorporate the changes. Update wiki subpage.
Week 11 Add feature of deleting the pushpins both in the widget and the android app. Test it. Get it reviewed by the mentor. Update the documentation. Update wiki subpage.
Week 12 Add functions for saving the static map as pdf. Add function to save pushpins related data in pdf format. Test it. Get it reviewed by mentor. Update wiki subpage.
Days Left Finish with function for saving pushpin data as text file. Test it. Get it reviewed. Refactoring the code built so far. Implement anything left over. Final Testing. Getting feedback of mentor. Incorporating all the changes. Cross Checking the documentation and updating it. As a result the project would be ready for final evaluation.
Final Evaluation

Experience of MediaWiki

I'm relatively new to mediawiki. It is through this project I came to know about it. But as a part of this project I'd read about the apis provided by it and have a relatively better knowledge now (familiar with the apis to be used in this project) and it would even get better in the course of this project.

Other Open Source projects I've worked on

I had started working with an open source organization Tux4Kids. I started with it recently and worked on the project TuxCoding.This project was started as a part of gsoc-13 and I'd added some more functionalities to it. Link to pull request.

Post GSOC Plans

I would like to keep contributing to wikieducator even after the gsoc period. In the gsoc period I would become familiar with the community ans its members. I would like to work on the app and extend it to display other content too (beyond what is offered in reader mode). Like maps, it could allow the users to edit the data. Thus I'll try to integrate most of the wikicontents with this app over the period of time. I also hope to be an integral part of your community and keep working with members. I hope to become a mentor for your organization next year.

Other Commitments between 19th May - 18th August

No I don't have any other commitments. There will be holidays from 1st May so my most of the summers would be free. My college will start form 1st August but that won't be a problem as most of the work would be finished by that time and I can easily work for 40-45 hours a week during the days left.