GSoC Student Applications 2009

From OpenStreetMap Wiki
Jump to navigation Jump to search

The following are some draft Student Applications for Google Summer of Code 2009. They may or may not have been submitted in this form by the April 3rd deadline.

Ian Dees is organizing the review of actual applications [1]. Everyone interested in mentoring or helping with the review should get in touch with Ian and/or sign up on the GSoC website.

Draft application: Static Maps API

See http://docs.google.com/Doc?id=df2wg5ch_30htttnwf3&hl=en

mailing list discussion

Draft application: Open Street Maps for Visually Impaired

Abstract

The application is a Keyboard accessible Directions tool using OpenSteetMap for Visually Impaired people (as well as general mass), such that maps can be used by all. It works on the principle such that,after user enters source and destination as his/her query in text boxes, the route or walking/driving directions are resulted as output not only on maps but also as detailed text explaining entire route(confirming to W3C guidelines),such that it is easily readable.

OSM Project Proposal

I have always been passionate about maps and that makes OSM my favorite organization. While browsing by list of Ideas by OSM, I find the one for Visually Impaired very interesting and since I am already working on two similar projects right now, so I intend to extend the knowledge into same.

Today, there are millions of visually impaired people who use Computer and Internet, they use Screen Readers like JAWS to email, fill forms, read articles etc. But there is something where Screen Reader fails, and that is, it cannot read image (no Screen Reader can).MAPS is one of those images which a visually impaired person cannot read. Hence, one of the most needed thing by them. In an attempt to solve it, many large companies like AOL have worked on the same (Please see > http://sensations.aol.com/sensations-app-accessible-walking-directions/ ) and their concept lies in the fact such that imagery result to a query is produced with text describing it in html .Once there is text as an output to the query, it can be read by Screen Reader (or any text to speech software).Basically text needs to confirm W3C guidelines (http://www.w3.org/WAI/quicktips/Overview.php )to make it Screen Reader enabled in the form of HTML header tags .

For the GSoC’09, keeping in mind the time constraints, I intend to develop a Directions tool using OpenSteetMap for Visually Impaired people (as well as general mass), such that after user enters source and destination as his/her query in text boxes, the route or walking/driving directions are resulted as output not only on maps but also as text explaining entire route(step by step) with major point of Interests and minute details like a Square/Junction/Traffic Signal etc (similar to the one currently implemented by MapQuest) ,confirming to W3C guidelines ,such that it is easily readable. The application will also help obtaining location of a specified business near a given address.

Currently the text based outputs are given in terms of either m/km or miles. I also intend to create metric convertor so that user uses the convention he/she is comfortable with and since it’s specifically for visually impaired a new metric included will be “foot steps” under long/short strides. So, that a blind user can actually count the number of foot steps and reach his/her destination (generally a blind will need the service for short distances, since they cannot drive on their own). However, directions for cars, walking, bicycle etc will be provided too (keeping in mind that the service can be used by all).

To implement the same, I intend to use CloudMade’s Library /APIs and Services like Geocoding and Geosearch in combination with Routing (the services are many complicated server machines, which could be accessed via HTTP, for the same there exists API wrappers in Ruby, Java and Python). I totally understand OSM Tags for Routing and explored various other options like OSMNavigation and LibOSM, GraphServer, Pyroute Lib and other services like OpenRouteService and YOURS which promises the implementation totally possible. For the text to speech, visually impaired people will use Screen Reader, however, to make the system machine independent I intend to develop application's own text to speech software using Washington University’s OpenSource project for Online Screen reader known as WebAnyWhere (http://webanywhere.cs.washington.edu/ ).Generally DHTML interface is difficult to access for someone using a speech-output interface,to solve the issue,the embeded XML metadata delivered by the application will be used to generate an audio-formatted representation of the content.

The application will be totally keyboard accessible with various short cut options, with very easy to understand interface such that people with Cognitive disabilities can also use the service with ease.

I commit to support and maintain the project post GSoC’09 in anyways possible and further expand the same in future. Please let me know, if any part of the proposal remains unclear.

Currently I am involved in

1-Research and Simulation based project on Interconnection Networks, developing a new adaptive load-balancing routing algorithm for X-Torus topology. Under the same project another routing algorithm developed is accepted for workshop at Parallel Programming Laboratory at University of Illinois at Urbana-Champaign, USA. Have submitted various other works under the same at different International Conferences and Journals .

2-Currently working on Internet Accessibility issues (for visually impaired people) for ASSETS'09 (http://www.sigaccess.org/assets09/ mentored by Dr. Shari Trewin from IBM Research ,who is also General Chair of ASSETS’09 ) and for Microsoft Imagine Cup's Accessibility Awards.

3-Still in touch with my mentor from One Laptop per Child ( OLPC - MIT Media Labs ) and maintaining Geography teaching software developed last summer using OpenLayers , MapServer , GeoRSS , QGIS ,which won 1st prize at International Conference on Contemporary Computing, India (co-hosted by University of Florida, USA ) .With my great interest in Research works and liking for maps,I am also looking forward to apply and work on paper for State of the Map'09 and contribute to OSM in anyways possible(through or not through GSoC'09).

4-I am also a member of International Association of Engineers and have been Fedora Ambassador-(India list) and member of University's LUG for almost an year now,and have contributed by organizing various University level workshops.

Time Spend

Since, I am graduating this mid- May’09; I can devote all my time till August while working from home , after which I expect date of joining from companies I have been offered jobs from (Tata Consultancy Services and Accenture) ,in September.

I break the time line as:

1-Community bonding Period (April 21 to May 22): Study minute details of the technologies involved in the project.

2- May 23 to May 31: Creating and designing workflow of the project and initiate coding.

3- June 1 to July 5: Completing the directions application by the end of it for blinds, still machine dependent and needs Screen Reader for the blinds. A cushion period of few days before deadline for mid-term evaluations .

4-July 14 to July 28: Implementing text to speech for the application, totally costumed for it and hence making it machine independent.

5-July 29 to Aug 5: Adding keyboard accessibility features.

6-Aug 6 to Aug 13: Testing and Documentation, with few days cushion time. End of project.

Handling Situations

Handling situations:

I am a quick learner and a comfortable team worker, I believe in self-study, almost all my technical skills are out of my passion to learn things on my own. In case my mentor stops responding, will report about the issue on mailing list, but won't let project affect from the same, instead will hangout more frequently on IRC/Mailing lists and other resources online, and assure that the project finishes well in time.

People

Submitter: --vaish.rajan 11:39, 02 April 2009 (IST)
Mentor: --Mikel 1:49, 15 April 2009 (IST)

OSM Comments

Feedbacks Welcome :)

Where is the download located? --Lulu-Ann 13:16, 21 January 2010 (UTC)

Hi Lulu, download is located at http://code.google.com/p/openvoicenav/ (under download section). Thanks.

Draft application: A GPX photo stamper

Abstract:

Almost every self-respecting personal photo application, whether on the web or on the desktop, supports geotagged pictures. Unfortunately, unless you feel like dragging every one of your thousand holiday pictures onto a map, it's not actually very convenient to getgeotagged pictures. Most gps-loggers and phones have some way of saving gps logs to the .gpx format. Wouldn't it be great if you could just upload your gps logs somewhere, and have your pictures tagged? Goal of this project is to create a (web)app to geotag pictures by matching the timestamp of pictures with the timestamp of the gpx-logs. The application will have support for geotagging directly uploaded pictures in the JPEG EXIF tags, and will also support geotagging existing flickr photo collections. (suggestions for more photo-sites with a public api to support?) Moreover, functionality to manually tag pictures by placing them on a map and synchronise timestamps by manuallygeotagging a single picture will be present.

Details:

Platform:

[TODO] - ask on the mailing list whether there are any limitations in the choice of web-platform.

GPX-matching:

This won't take too much time to program:

  • If both the GPX-logs and the date-sorted pictures are available up front, the best strategy would be to traverse both the logs at the same time, every time 'waiting' for the later timestamp until the other caught up.
  • If we get the gpx-tracks along with a large set of unsorted-in-time pictures, it might be a good idea to built a binary tree with timestamped gpx logs. This will allow us to find the two nearest gps-logs for every picture in O(log n).

Photo-mapping:

Time-synchronisation and manual tagging will be performed by dragging small thumbnails on the gliding OpenStreetMap map. I will propose a more detailed GUI design to the mailing list as part of my project.

Flickr support:

The Flickr web-api will be used to geotag existing collections of pictures on flickr based on uploaded gpx logs. We will put this interface in a plugin as much as possible, to make it easy to add other web-apps.

Desktop Application:

As far as I could see, there are no cross-platform open-source applications to geotag a personal photo collection based on gpx-logs jet. If there is enough time left, I would like to write a cross-platform desktop-application with similar functionality to thewebapp . This would allow users to tag photo collections that they don't want or are too large to upload. This application would use theOpenStreetMap maps, and can draw further attention. I would like to use 'qt' as a cross-platform GUI toolkit in this case.

Deliverables

I'll use the MoSCoW method to prioritize my deliverables. A deliverable is complete when it's coded, tested and documented.

  • Must-have
 The web-app complete with gpx-matching, timestamp synchronisation, and manual geocoding.
  • Should-have
 Flickr support
 evt. support for other web-apps.
  • Wanna have
 A desktop-application with similar functionality.

Preliminary planning

Coding officially begins at May the 23th, and ends around August the 10th, which allows for 11-12 weeks of dedicated work. To allow for unforeseen circumstances and delays, I will plan for eleven weeks.

  • before: Get to know the project and the community. Talk about initial ideas, and research what's already there that I can use. Get to know theapi's and webapps that I want to use.
  • week 1-2: Implement both gpx-matching algorithms in platform of choice.
  • week 3: Discuss and design a GUI for this project.
  • week 4-6: Implement GUI with functionality for comfortable timestamp-synchronisation and manual geotagging of pictures.
  • week 7-8: Implement Flickr-support in a plug-in.
  • week 9-11: Start with porting web-app to a desktop-app.


My 'real' application including information about me and a motivation etc. has been submitted at the GSoC website.

People

Submitter: Tijs Zwinkels 0:40, 1 April 2009 (UTC +2)

Possible Mentors: --Mentor name(s)--


Draft application: Automatic Street-Sign Detection and Reading

Goal of this project is to implement a system to detect street signs in geotagged pictures, and eventually to automatically read the street-names from the detected signs. This could lead to less time-consuming and in the optimal case near-automatic mapping based on gathered gps tracks and timestamped pictures of street-signs. This project contains two distinct phases. In the first phase we'll work on robust street-sign detection and segmentation. In the second phase, the focus will shift towards automatically reading the text on the street signs. This idea was originally proposed by Stefan de Konink, and was born on the openstreetmap dev mailing list. See this post.


Scope

I realize that this is a large project. In order to be able to complete this within the time for the Google Summer of Code, it is important that we define the scope and priorities for this project.

  • First priority and most important deliverable is a system to detect street-signs. This will already allow for easier mapping / coding, because the author of the map will be able to find street names easily. If there's enough time, we will extend the system to automatically read the street-signs as well. I fully expect to keep on working on this project after the Google Summer of Code ends.
  • Since street-signs look differently in different parts of the world, for now I'll just focus on dutch street-signs. I think this will give me enough variance to struggle with for now. :) - ofcourse, it shouldn't be hard to adapt this work to foreign street signs.
  • There is a large difference between whether the software should be able to catch and read street signs that just happen to be in a picture, or whether people took a picture with the intention of capturing a street sign. (by which we would view the sign from a relatively straight angle with a reasonably high resolution, not too much reflection, etc)

For now I'll assume the latter case. If the performance is reasonable, we can always scale up to the more difficult cases.


Street-Sign Detection / Segmentation

Before we can read the street-signs, we need to know which part of the picture to feed to the OCR software. For this we need to detect the street-sign, and find some reasonable way to segment it.

SIFT:

[ http://en.wikipedia.org/wiki/Scale-invariant_feature_transform SIFT] is the current algorithm of choice for object detection from different angles in different conditions. This seems a logical first-choice for a street-sign detector and segmenter. Moreover, the OpenStreetPhoto spin-off project is already working with SIFT, and I hope to be able to draw on their existing experience and work.

automatic feature mining:
  • run a largish database of cropped streetsign pictures through the SIFT feature detector. Features that occur in the vast majority of the streetsign-images are likely good features for a streetsign-detctor.
  • run a largish database of pictures taken 'on the road' not containing street-signs through the SIFT feature detector. Features that occur very often in that database and occur in the former database as well, are likely to give false positives and should be pruned.
manual feature selection
  • it might be nice to have a tool that views the SIFT features generated per traffic sign, which allows us to disable the features of which we're sure that they are not generic to traffic signs. For example: features generated from specific letters on traffic signs are not general to the 'street sign' class of objects, and these features should not be used for detecting street signs.

color-histogram matching

One feature that all dutch street signs have in common, is the distinct blue color. Unfortunately, the same color can look rather different in different conditions on different camera's. A common approach is to fit a gaussian mixture model* to the color-histogram of the subject, and use this for recognition. I have an article laying around (and have used this for my graduation) applying this to skin-color detection. I'll post the reference as soon as I find it.

structural pattern recognition

Structural pattern recognition takes the relation between features into account. We might be able to use these techniques to improve recognition based on trained knowledge such as 'a street sign consists of a blue surface with white letters above a metal pole'. Often graph-matching techniques are employed for this. See the reference on wikipedia and 'Schurman (1996) - Pattern Classification: A Unified View of Statistical and Neural Approaches' (ouch, expensive).

texture-based methods

Another 'traditional' computer-vision method is to generate features based on texture. For a relative close-up and sharp picture, the street sign might have a different, smoother texture then surroundings such as stone, road, grass, etc. Methods to compute features / distances over texture include gradient-direction histograms, co-occurrence matrices, and Laws texture energy.

image segmentation

We could also try to approach this problem not so much as an object-detection problem, but more as a segmentation problem. We could use per-pixel classification and segmentation of regions with a certain density of positively classified pixels,clustering methods, or region-growing.

other methods

Depending on the performance, we can try other detection methods such as haar-like features*, and other feature detection methods*. Multiple classifiers / features could be combined by using Boosting*. A promising approach can be found in Torralba et. al. (2004).

Street-Sign Reading

After we've found and segmented the traffic signs, we need to be able to extract the text written on them.

  • The first step is definitely to try existing open-source OCR solutions, such as OCRopus / Tesseract. - Even if performance is not very good, it is probably better to try and improve existing software than to built an entirely own system.

Some ideas about a text-extraction system:

  • For OCR it's often very comfortable if we know the words that we can expect up-front, so we can perform holistic word recognition and sidestep the letter-segmentation problem. If there's a database available with all the street-names in the Netherlands, that would actually help a lot! - For now I'll assume this is not the case.
  • If we have a reasonable segmented picture of a street sign, we can segment the letters by finding local minima in the vertical-brightness-sum histogram of the image.
  • A method is to convert the letters to a low-resolution grid, and classify them using a neural network trained with back propagation.
  • Another method is to extract simple features from the letters, and use other machine-learning classifiers*. There is a lot of literature about this. (TODO: literature)
  • A hidden-markov-model*, trained with all currently known street-names in the Netherlands, could be used to calculate probabilities for a number of hypothesis generated by the OCR system, and could greatly improve performance.

Previous Work

Generic text-extraction from natural scenes:

References *

I personally like wikipedia for these kind of references, because it provides a lot of background, context, and further reading. If more scientific references are preferred, let me know and I'll add them.

Deliverables

I'll use the MoSCoW method to prioritize my deliverables. A deliverable is complete when it's coded, tested and documented.

  • Must-have
  * A detection-system for dutch street-signs coded, tested and documented along with a tagged picture database.
  • Should-have
  * The detection system implemented and documented in JOSM, so people can start using it to code their maps.
  • Could-have
  * A system to read the street-names from the detected street signs.


Preliminary Planning

Coding officially begins at May the 23th, and ends around August the 10th, which allows for 11-12 weeks of dedicated work. To allow for unforeseen circumstances and delays, I will plan for eleven weeks.

  • Before / first week: Get to know the community, platform / tools, and gather a dataset. While I'm out there, I might just as well do some mapping and get to know JOSM.
  • wk1-5: Start research and work on a robust street-sign detector. Find out which methods work and which methods don't. Try to gather as much data as possible on the workings of different algorithms in different circumstances.
  • wk6: Decide on the best method to perform street-sign detection, implement this method in a library / JOSM module, write a test-suite, a write documentation.
  • wk7: Integrate the street-sign detector in JOSM gui in a way that actually helps people mapping.
  • wk8-10: Start research and work on a robust street-sign reader.
  • wk11: Final implementation / bug-fixes / Documentation.

Notes:

  • If this system offers reasonable performance, I think we have something that we can definitely publish in some computer vision journal. Any mentors interested in maybe eventually co-authoring an article?
  • The ai-department of the University of Groningen has a 'Handwriting Recognition' research group, and the supervisor for my graduation project is part of this group. I know them well and can ask them for tips on the OCR / streetsign reading part of the project.
  • I've written a little piece of handwriting recognition software as part of a course. It's not very good, but at least I can use what's already there.
  • This is my second proposal for the OpenStreetMap. If it was to happen that multiple projects made the cut for the GSoC, I would personally prefer to work on this project.
  • My 'real' application including information about me and a motivation etc. has been submitted at the GSoC website.

People

Submitter / Interested student: Tijs Zwinkels.

Possible Mentors:

Accepted!

The project has been accepted :D ! Tijs will be the working on this project from May the 23th to August the 17th 2009. Mentoring will be provided by Stefan de Konink.

I've created a new wiki-page to track the project as it progresses: Automatic Street-Sign Detection and Reading.

Draft application: OSM knowledge headquarters

Abstract

This project aims for collecting mapping elements and putting them in a re-usable module usable in other OSM projects. Currently such information are scattered around different parts of OSM. This knowledge will be collected, structured, put into an OWL ontology, packed together with a reasoner and offered through an API tailored for OSM or GIS generally. Initially the API will be done in Java and applied in a JOSM plugin. Other languages could follow later.


Motivation

  • Putting all definitions of accepted/proposed map elements in one place for effective administration.
  • Maps easily readable for human as well as for computers. Single ontology also allows to translate human-readable definitions to key-value pairs in OSM. This will simplify the user interface of map editors to attract more users. Integration with Semantic Wiki will allow to implement a contextual help usable the same way as it is done in modern IDE for aiding programmers.
  • The wiki documentation will benefit by allowing users to ask different questions than nowadays. Currently users can ask questions like: "What do highway=path or foot=yes mean?" But most users want to ask: "How can I express that a way is suitable for walking on foot?" Creating a structured ontology allows this easily.
  • This project does no restriction to allowed key-value pairs, which can be put in the database. The ontology should be viewed more as a guideline than restriction.
  • Handle region specific delicacies. For example in Czech Republic there are very specific tourist signs. In the proposed system such knowledge could be easily incorporated, but still filtered out easily for different countries.
  • Creating an OWL ontology will prepare OSM for expansion of semantic web.

Deliverables

The core of this project would be the ontology with OSM elements and Java API for communication with it. It is likely that for a JOSM plugin using the ontology would be created to display possibilities of this technology.

Used technology

  • OWL (Web Ontology Language) for expressing the ontology
  • FaCT reasoner - allows to do inference in the ontology. FaCT is implemented in C++ and has Java API, which makes it ideal for projects with wide range of programming languages like OSM.
  • Java

Initial time plan

  1. Designing and implementing the ontology.
    1. Discuss the ontology design with community members interested in knowledge management. (2 weeks)
    2. Creating the ontology (3 weeks, partially in parallel with 1.1)
  2. Integration with a reasoner. (1-2 weeks, the dependency on previous points is not strong)
  3. Designing the API.
    1. Design (4 weeks, a lot of consultation with the mentor and other OSM developers will be necessary)
    2. Implementation (1 week)
  4. Creating the JOSM plugin, which will also serve as testing. (remaining time).

Personal data

Your name: Radomír Černoch

Your e-mail(s): radomir.cernoch@gmail.com, r.cernoch@sms.ed.ac.uk

Please list the programming languages you are proficient in and rate your proficiency from 1 to 10 (10 being greatest proficiency): Sorted according to relevance to this project: Java SE (8), C++ (6), SQL (8), C (7), PHP (8), Prolog (9), Object Pascal (10), Java Script (4), Bash (6), Lisp (7), Matlab (9), Maple (8), Assembler (3), CAML (2) and various strange languages like Promela or AgentSpeak.

What interests you in the OpenStreetMap project? I have always liked maps and OSM allowed me to try creating them. Now I thought I could contribute to this project with what I have learned during my masters course at University of Edinburgh (knowledge engineering specialism).

What activities are you currently involved in (related to computer science, programming, or mapping)? I am maintaining a few packages for openSUSE project (in the Contrib repository) and recently I have started mapping for OSM around the places I live in.

How much time do you plan on being able to spend on your Summer of Code project? My time schedule over summer will be probably quite tight. But I am sure I can devote at least 2 full days a week to this project. What I can say for sure is that I would be working on this project regulary, a few hours a day, which should prevent delays.

How would you handle a situation where your mentor does not respond to your questions? Firstly I would ask the mentor's friends from the community if something happened to him. Then I would contact Google and ask the OSM community (mailing lists are useful for this) for help with particular questions. So far I have found people around OSM really willing to help.

Do you have any other hobbies or interests? Apart from programming I like reading (mostly beletry and philosophical books), politics, then photography (actively) and other arts (passively). If any time is left I enjoy swimming or riding a bike.

Draft application: Improved Altitude Server

Abstract

People who cycle a lot in areas they don't know well usually want to have not only the map, but also a heightmap. Currently there's no centralized altitude server that would serve elevation data for the whole globe in a machine-readable form.

Planned features

  • Compatibility with the existing route altitude profile server while being much faster and not so disk-space-consuming;
  • Enriching usual SRTM tiles with data from GPS traces and, probably, other sources;
  • Serving binary elevation data for the requested bbox with requested level of detailisation;
  • Render of elevation data into graphical formats, for compatibility with OpenLayers / OSM Editors for areas where no sat image is available;

Details

Your name: Darafei Praliaskouski

Your e-mail(s): me@komzpa.net

Backup means of contact (Facebook profile, Twitter account, LinkedIn, etc.): +375 29 1527849; +375 25 9763231; twitter:komzpa; xmpp:me@komzpa.net

Please list the programming languages you are proficient in and rate your proficiency from 1 to 10 (10 being greatest proficiency): Python:8; shell:7; C/C++:6; basic/pascal:9


What interests you in the OpenStreetMap project? I have a bike and gps. There won't be maps of detalization I need unless I draw them :)


What activities are you currently involved in (related to computer science, programming, or mapping)? OSM Belarus, in top-nine of mappers.


How much time do you plan on being able to spend on your Summer of Code project? No problem to spend 2 hour a day.


How would you handle a situation where your mentor does not respond to your questions? There's the whole google to search for solutions, if no coders/mappers of OSM Belarus team know the answer.

Do you have any other hobbies or interests? KDE localisation (belarusian), cycling. Trying to hardmod nokia n800 to be a cycle computer.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=GSoC_Student_Applications_2009&oldid=422713"