Google Summer of Code/2010/Project Ideas

From OpenStreetMap Wiki
Jump to navigation Jump to search

This is our project ideas page for Google Summer of Code 2010.

For more lists of project ideas see the Student projects, and Things To Do pages.

If you're interested in what type of ideas were proposed by students in 2009, please see GSoC Project Ideas 2009. GSoC Student Applications 2009 page is just some drafts, you can create new one's at Google Summer of Code/2010/Student Applications. Start sharing your ideas with OSM community by editing this page in the format mentioned, and start a discussion on the OpenStreetMap Developers Mailing List to seek opinions on your ideas.


OpenStreetMap Data Projects

Point of Interest search and presentation

Objective

Provide a collection of tools for POI look-up (by location and/or text search) and presentation (clickable map overlay, human readable list).

Most important part of the project is a high performance, live POI API that can be used by web applications, desktop applications and mobile devices.


Introduction

I would like to introduce my idea for GSoC. We already have many POI details in the database (opening hours, website/wikipedia article, phone, ...) that are not very accessible to the end user. There is also a growing demand for an easy way to display icons for rare tag combinations, like new OSM for the blind tags, "fuel stations" for electric cars, pubs for smokers, and so on. My experience is also that mappers are highly motivated if they can view their special details.

I was inspired by the demo introduced at SOTM09 and the OpenStreetBrowser and tried to build a map with clickable POI overlays (no tiles, but OpenLayers markers) that would provide the tagged details as human readable text when the user clicks an icon.

This is in a proof of concept state and turned out to be useful (i.e., for the OpenLinkMap).

If you want to support any possible tag combination with reasonable performance and also be up to date (at least daily updates, aiming for real-time) in my opinion none of the existing API solutions is suitable.


This is where the project idea comes into play: MonetDB seems to have the right capabilities and can be extended with spatially ranked text search features.

The project could provide the API (including text search) and usage examples, i.e. an OpenLayers example to build a map for end users (and mappers) making the existing data more accessible in terms of search and presentation.

Details

POI lookup is supposed to be possible for any tag combination on bounding boxes and polygons. Additionally there should be a location based text search with ranking (via Sphinx).

Approaches using the XAPI, API_v0.6, cached XAPI results, Planet.osm extracts, a Planet import into PostGIS (osmosis or osm2pgsql) or MySQL suffer from one or multiple of the following problems:

  • long response time
  • no regular updates
  • limited area
  • small selection of supported POI types

This project is supposed to be free from all these issues. It will be based on MonetDB for improved performance and geospatial features. POI data will be available in various formats (KML, GeoJSON, GPX, etc.).

To demonstrate API features and ease the inclusion in OpenLayers based maps the project will provide an OpenLayers class for adding clickable POI overlays with any tag and chosen marker icon. This will enable mappers to make their own custom POI map and visualize their mapping work immediately.

Lists like "Museums in Central London" or "Restaurants in Karlsruhe", showing details formatted from OSM tags in a human readable form, may be a motivation for mappers to add more details and are also useful for actual users not knowing about OSM tags at all. Human readable output could also be used by other applications, for example an online travel guide or a POI review platform.

Besides the raw tag information and human readable formatting this project could try to enhance the information (if desired), by adding information like country, timezone, city, postcode, associated street and probably more (live from relations if possible in terms of performance); smoothening output ("contact:phone", "addr:phone" and "phone" are equivalent and could be returned as "phone") and checking for possible misspelled tags (uppercase etc).

To be prepared for real-time updates from the OSM API the update process could read AMQP messages like OSMdoc will do (see TRAPI discussion on dev list). It needs to be checked how precalculated geometry columns (linestring, polygon, multipolygon) on ways and relations affect performance of queries and updates.


This project covers #Interactive_Point_of_Interest_Map and Things_To_Do#POI_layers.

People

Submitter: Emka

Possible Mentors: Stefan de Konink

OSM Comments

Add your comments here. Use four tildes to mark your comments.

See the Mapnik GSoC application. I would far rather see people working on this in core Mapnik than producing an off-the-wall project for OSM. --Richard 21:30, 14 March 2010 (UTC)

I am not sure about that - I always think of Mapnik as being a renderer, whereas this is more of a database project. The Mapnik version will rely on embedding metadata in the rendered map tiles, so the available information will be limited - this approach would be more flexible, as long as it can be made quick enough to be useable. The proposer seems to recognise the performance requirements, which is a good start! - Grahamjones 22:26, 15 March 2010 (UTC).
There is no rendering involved in this idea. I will try to explain the idea on the dev list.--emka 13:23, 20 March 2010 (UTC)

Develop a Simple, Stand-Alone Editor for New Users

The purpose of this project is to develop an intuitive very easy to use editor for use by new mappers who are not familiar with the more fully featured editors like Potlatch and JOSM. The features will be very limited, with the objective being ease of use for simple tasks such as:

  • Renaming nodes and ways
  • Adding single node Points of Interest, with preset key/value pair options for simplicity (similar to Potlatch).
  • Simple changes to geometry? (this may be a step too far for this editor)

The editor should run from a web page so that the user does not need to install software. This means that it will need to be JavaScript, Java Applet, or Flash application.

Grahamjones 22:42, 8 March 2010 (UTC)

Improve Usability of a Simple Mobile Phone Map Editor

The objective of this project is to enable users to carry out simple map editing tasks on a mobile phone. The Vespucci editor for android is an example, but it suffers from usability issues. A project along these lines should identify the issues with the existing application and propose improvements.


Porting of Potlatch to use FLOSS tools and viewer

The potlatch software should run on gnash, and be able to be used and expanded upon using only FLOSS software.

Potlatch 1 already runs on Gnash and compiles with Ming. The Gnash devs have put a great deal of effort into this and continue to improve it. If you'd like to help them provide AVM2 support so that it can run Potlatch 2, that'd be excellent, though it's probably more a Gnash project rather than an OSM one. --Richard 10:53, 11 March 2010 (UTC)

Develop a Simple Mapping Tool for Mobile Phones

Many mobile phones contain cameras, microphones and GPS receivers so it is possible to take geotagged pictures and audio clips and record GPX tracks. Some software exists that does this, but there is not a simple application that makes these tasks easy, 'one click' activities as they tend to be included as ad-ons to more complex applications.

Generate structured output format

Details

The current OSM export format contains very limited hierarchical information and what information is available is generally not structured in a way suitable for rapid access. Various applications could benefit from a more structured planet output format which rationalises the raw OSM data. This problem has various aspects from dealing with very large volumes of data, multi-language support, dealing with only partially defined data and estimating data for poorly defined areas.

Background

At least 3 existing projects have approached this problem and might be used as a basis:

Technical Issues

In order to deal with anything but small extracts significant server resources would be needed.

People

Submitter: Twain 12:28, 12 March 2010 (UTC)

Possible Mentors: Brian Quinion

OSM Comments

JOSM Audio Waypoints (an audio analysis project)

To analyse an audio commentary to identify and timestamp verbally identified information.

Details

One method of mapping is to make a GPX track and a continuous voice recording. A mechanism already exists to synchronize the audio with GPX waypoints/named trackpoints, so that you can click a marker and hear what you said at that point. However, this depends on pressing a button on the GPS device to mark the waypoint (sometimes many buttons). It would be very convenient if the audio markers could be generated by recognising a word or phrase within the audio track instead (then there are no buttons to press). For example say "MARKER: Wibble Street" and we can get a button at the word MARKER.

Integrating with JOSM is straightforward, so the task boils down to analysing a WAV file (specifically WAV, please, because of the limitations on the Java audio playing library and also the ability to vary speed and have easy direct access to jump to a particular timed point in the recording) and creating a list of timestamps at which the chosen phrase is present. Ideally the phrase should be determined by a sample recording or recordings (so it can be trained). It needs to work in a relatively noisy street environment (so should probably err on the side of more rather than fewer false positives) and needs to cope with recordings of several hours and hundreds of instances of the key phrase. Ideally written in Java for easy creation of a JOSM plugin at some stage. The final list could be a separate structure (e.g. an XML file) or could be appended to the WAV file as a set of labels (WAV supports this).

People

Submitter: David.earl 09:19, 10 March 2010 (UTC)

Possible Mentors: David.earl

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Ordinary voice detection (saying anything) might be easier and would still be useful if the gpx trace could be marked, by for instance color or boldness. With continuous recording and no markers, I would like to find the useful stuff among hours of heavy breathing and vehicle noise. Chrismorl 21:01, 14 March 2010 (UTC)


UI for reverting data in JOSM

Details

The OSM database manages the complete history of every OSM data object. Because both the database and the community grow it is more and more often necessary, that a edit has to be undone and the state of one or more objects have to be "rolled back" to a former point in time. In OSM this is called reverting.

Traditionally, JOSM mappers use scripts to revert OSM data. If mappers had a more intuitive and supportive UI at hand for revering OSM data, they could more efficiently maintain OSM data, in particular if an edit of their own or of one of their fellow mappers went wrong.

The advanced OSM editor JOSM should therefore support reverting functions like:

  • Reverting of a single object. Reverting of the state of an individual object to former point in time, either of the complete state or subsets therefore. The reverting function would allow to revert the tags, the position, the relation member list, or the node list of way only. It would also allow to revert any combination thereof.
  • Reverting of a changeset. Reverting of the objects participating in an changeset to the state before the changeset was applied.

People

Submitter: Gubaer

Possible Mentors: Gubaer

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Improved conflict resolution in JOSM

Details

The OSM database uses optimistic locking to identify and prevent conflicting edits on OSM objects. It is up to the mapper to resolve these conflicts, though. In case of conflicts he or she is responsible to "merge" conflicting data sets into a resulting dataset. He isn't able to upload geo data unless it is free of conflicts.

The advanced editor JOSM therefore provides an UI for resolving conflicts. It is designed and implemente to resolve one conflict after another and each resolution requires a rather complex sequence of mouse clicks. It is very time consuming to clean datasets with more thant ~10 conflicts from conflicts. Compared to the observation that large edits sometimes generate dozens or even a few hunderts of conflicts, mainly in areas where a lot of mappers are mapping concurrently, this is far from optimal.

JOSM should therefore be extended with next generation support for conflict resolution:

  • classify conflicts according to type of conflict (state conflict, tag conflict, position conflict, etc.)
  • classify conflicts according to severity (find a suitable metric, classify conflicts, and visualize them)
  • visualization and manipulation of these conflict classes
  • functionality to select and resolve batches of conflicts with a certain type and a certain severity

People

Submitter: Gubaer

Possible Mentors: Gubaer

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Multiple improvements to OpenSatNav

The use of mobile platforms for OpenStreetMap is rapidly growing, so we need first class software for people to use. OpenSatNav is an existing project for the Android platform. My proposal details several "improvements" which will take OpenSatNav to being a first class navigation product.

People

Submitter: evolvedlight

Possible Mentors: Kizza

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Boundary objects to manage inheritable data properties

Objectives

Usually, most objects in OpenStreetMap can be adequately characterised by default properties attached to the type of object in consideration. However, many regions in the world, be it a country, county, town, or other type of categorisation, often have properties that are peculiar to the region in question.

Thus, it seems best to characterise objects through a mixture of default and specific tags, based on a hierarchy of geographical boundaries. For most cases, the default attribute tags would suffice, but where present, explicit tags would override these. The tagged properties on the boundary objects would translate into a tagging style on the objects inside, much like CSS attributes are used to style objects in a DOM structure.

Technical Issues

Tasks will be:

  • tagging of such boundary objects
  • data representation in the OSM technical environment to serve queries for such objects
  • technical infrastructure needed to support queries for such objects (->performance)
  • API functions to support such queries
  • definition of use-cases to be used as introduction and as a pilot-project to test such a function's versatility

Spending some thought on the platform which executes these functions could get vital. The calculations needed are not trivial and demand some computing power and data thruput on the server's part. Whether transforming the resulting data as a batch job or better on request should be well considered. Offline use makes implementation client-bound and thus platform-dependent, whereas an online implementation can be maintained easier and adds less complexity while still supplying a common infrastructure for this task. A distributed caching technique may supply some benefits, but adds a lot to complexity.

  • Care must be taken in deciding, in case of conflicting tags, which value gets precedence. There might be need for a kind of policy syntax.
  • Objects intersecting with boundaries may be divided into sub-objects to be handled individually. There is currently no support for such data.
  • The project can get really demanding and needs to be truncated somewhere.

People

Submitter: --Thomas Meller--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

To find the start of how the ideas evolved, see the original idea's post and where the stone started rolling.
Tmeller 15:53, 16 March 2010 (UTC)

The idea is still hot off my brain and still evolves a bit. Especially concerning my lacking knowledge of the English language. Updates and new drafts will get visible at first here: Project drafts.
Tmeller 15:53, 16 March 2010 (UTC)

POI Collector

We use maps to find the location of places which we need to visit (like shops, banks, cashpoints etc.). These points are called Points of interest (POI) and there are essential for map usability. The idea is about creating a POI Collector which would be platform independent and will work on all mobile platforms (android, iphone, blacbkerry, ipad and so on). That goal can be achieved by creating POI Collector as browser application.

Objective

- To simplify and accelerate collecting of POI.

- Easy in use mapping application will support involving new OSM users in mapping. They are able to use intuitive/simple tool without any previous mapping experience.

- To provide POI Collecting tool for all mobile platforms.

Description

Application will display map (map tiles will be downloaded from mapnik) and current user position (coordintaes will be read from GPS device). When user reach some point (e.g. bank) which he would like to add: he just clicks Add New POI and point appears in user current location (in case when such point already exists in database, user can edit its properties). In adding form user specifies type of point, and its attributes (like name, description and so on, node properties depend on type of just added POI) and save them by clicking Save button (data are saved by proper create request to OSM API). Editing the OSM data requires being logged to OSM account, so when user click Add new POI for the first time he is asked to give his OSM login and password

People

Submitter: pniecho

Possible Mentors:

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Image Rendering Projects

No specific rendering projects have been suggeted directly for OpenStreetMap, but Mapnik, which can be used to render OpenStreetMap data has been accepted, so you could look at applying to that project if you are interested (Mapnik Ideas Page).

Alternatively you can suggest your own rendering idea here!.

Routing Projects

Travel Time Analysis

Objectives

Routers need to estimate the time it will take to travel along stretches of roads.
This can be attempted by using speed limits, a 'sinuosity' assessment of the road, but these can not allow for traffic density.
An average travel time for segments of roads of different kinds, lane-count and at different times in the OSM database could be calculated using GPX traces (maybe even the ones stored in the OSM database) or done while the user is driving ? This information could be stored in a relation for each segment of road to be used to help routers estimate travel time (the code to produce the relations was produced during the 2009 GSOC for elevation changes, so this could be an extension of that code).

Technical Issues

A source of GPX traces will be required - need to check if the traces in the OSM database are suitable or not. It will be necessary to match GPX traces to OSM ways - this could get difficult if there is no way covering the trace, or if the GPX fix is noisy (such as in built up areas). The program will have to filter out car, bicycle and foot traces as well as car traces behaving different due to the driver mapping instead of traveling, which could limit its usefulness in towns, but it should be ok for major roads. --Grahamjones 22:23, 11 February 2010 (UTC), --MarcusWolschon 18:47, 12 March 2010 (UTC)

People

Submitter: --Submitter name--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.


Minutely updated routing

Objectives

Routing can be quite demanding on the quality of data, as even small local errors can have large scale implications on the calculated routes. Thus good Quality Assurance tools are necessary for routing. In addition to the already existing tools focusing on specific bug types, simply using the data for routing offers a good quality judgment. However, for it to be useful to aid fixing data issues, the turn around time from changing the data to updating the routing graphs should be as small as possible. The project would thus be to create a scalable web based routing api that can be updated using the minutely or hourly osm diff files. Ideally it should integrate or re-use as much as possible the existing efforts for web-based routing with OSM (e.g. YOURS/ Gosmore, Traveling Salesman or pgrouting)

Technical Issues

Dealing with the entire planet is very resource intensive. Careful considerations would be needed to ensure that any algorithms used are scaleable enough, yet still don't need large amounts of pre-processing to be able to update them rapidly (minutely or hourly). It would also need to support sufficient amounts of the routing relevant tag sets (e.g. turn restrictions, access tags, maxspeed) for it to also be a viable quality assurance tool.

This proposal is not fully worked out and careful planning is needed to make sure the project scope is feasible and appropriate and does not duplicate existing efforts.

People

Submitter: --Submitter name--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Paper Output Projects

Easy Printable Maps

Objectives

Provide a method for users to easily print maps - ie select scale, features to render (including contours and/or hill shading), output page size. Large areas should be split into tiles to print on individual pages and attached together, or turned into a book that can be stapled together. The objective should be professional output (with OSM branding!).

Technical Issues

Fairly straightforward - there are a few working examples (maposmatic, townguide, pdfatlas), but I would like to see something flexible and easy to use. It could either be a desktop application or web service --Grahamjones 22:23, 11 February 2010 (UTC)

This would be cool, but would need clear goals: e.g whether the output is targeting maps to print or map export that can be edited (post-processed) to be printed. I can see value in a project focusing on either, but the latter is what is most missing in the other offerings you mention above and is captured nicely here: http://wiki.openstreetmap.org/wiki/User_talk:Nicolasmarichal. To do this you'd need a nice web application plus some customization of the rendering toolkit used. For example, if Mapnik were used, the student could help test existing patches and improvements that would be needed to support proper multi-resolution output: http://trac.mapnik.org/ticket/320 and http://trac.mapnik.org/ticket/389 and http://trac.mapnik.org/ticket/343. I would be interested in mentoring on this and see possibilities for cross-collaboration with other projects that may have other print/multi-resolution based GSOC projects like OSGEO (see http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Engine#Ideas_for_Summer_of_Code_2010_Project). Also the Mapnik project is applying for GSOC independently so it offers an opportunity to perhaps have two students working on this, one focusing on improvements and features in Mapnik (http://trac.mapnik.org/wiki/GSOC2010/Ideas) and the other focusing on the web interface and the specific issues faced with turning OSM data into print products. --Dane Springmeyer 9 March 2010

I hadn't seent [[1]] - what is suggested there is exactly the sort of thing I was thinking about - I have started it with townguide, but that only does POIs over a 'standard' mapnik rendering at the moment - problems are resolution, lack of rendering options and scale - I currently use a standard mercator projection and assume that those metres are real - to do this properly you should chose a better projection for the area you are rendering - I fancy centering the mercator on the centre of the map, but haven't tried that yet!

I sent the following comments/suggestions to a prospective student yesterday: The issue here is not that there is a lack of code to produce printed maps - the main OpenStreetMap page "Export" tab lets you create a PDF, MapOsMatic allows you to produce printable maps with street indexes (indices?) and townguide lets you select various points of interest to highlight on a map. There are also other utilities on the OpenStreetMap "On Paper" wiki page. The issue with these for me is that they just produce similar images to the main on-line maps - the nice thing about OSM is the ability to customise your maps to show what you are interested in - for example there could be options targeted for out-door use with contours or hillshading (like OpenCycleMap), you could customise the colours of motorways and trunk road to match what you are used to seeing in your country. If you are planning a one way cycling trip, you might want a map over several pages that is not a simple rectangle, but follows the route. You also need to be careful with image resolution - you need a lot higher resolution on paper than you do for a computer screen - the reason I have not promoted townguide yet is that its image resolution is too low so the output is not as nice as it could be. Therefore I think this suggestion is one about integrating existing ideas to make it easy for the casual user to print out a map that is useful for their application. One of the hardest parts will be designing a user interface to avoid it being really complicated with all of the possible options. - Grahamjones 08:10, 10 March 2010 (UTC)

People

Submitter: --Submitter name--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

It's probably worth considering the possible projections when generating paper maps. I've done a bit of work adding projection support to Osmarender/orp, though it's not yet committed. --tms13 14:03, 19 March 2010 (UTC)

Web Projects

Interactive Point of Interest Map

Objective

Present a basic slippy map with the option for the user to select points of interest to be displayed as markers on top of the base map. These could be restaurants, hotels, tourist attractions, bus stops etc.

Technical Issues

Data handling - I think I have seen something that tries this, but it was very sluggish - to make this useful the data source will need to be selected carefully - xapi may be too slow, so may need a 'POI only' database to make it quicker, or even deliver the data as a file to go with each map tile. OpenStreetBrowser seems to have pretty much done this idea (but the PoIs only select when you hover over them in a list), so there might not be much scope to develop this as a project? --Grahamjones 22:23, 11 February 2010 (UTC)

I started developing a similar application a 2 weeks ago (demo, code). Though instead of OpenStreetMap POI I'm using points from open data sets. Currently it just has 6000+ bus stops in the Ottawa Canada area, but there will be more to come when the city opens up more data. I have a jQuery based AJAX marker manager that is pretty smart (markers show popups when clicked, only markers in the visible area of the map are loaded, markers don't overlap, as you zoom in you see additional markers, etc). The XML used in the AJAX is in GPX format which makes it easy for other applications to interface with my app. There is also a caching mechanism to reduce the database load. I'm currently a full time student, and if I can accomplish that in 2 weeks (during midterms), then this task is definitely too small in scope to be a summer project. --tcort 00:29, 19 March 2010 (UTC)

Ah but not all students are as smart as you. Your project is impressive (particularly as it only took a couple of weeks). I see you're showing loads of POI types on http://opendatamap.ca now. Lets create a wiki page here about it: odopoi. If I get chance I'll try setting up my own odopoi server. -- Harry Wood 10:37, 27 April 2010 (UTC)
You might want to use Openlayers.Layer.Vector with OpenLayers.Strategy.BBOX as it will make panning smoother. OpenLayers will take care of marker loading and management. --emka 19:11, 27 April 2010 (UTC)

People

Submitter: --Submitter name--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.


OpenStreetMap Mashup generator

Objective

Create a simple web mashup generator for use with OpenStreetMap data, based on OpenLayers. A user should be able to use OpenStreetMap data in the way he wants on his website or take a print out. The mashup generator would assist them to choose the map area, select the type of renderer, select the zoom levels. The user can then, input his data to show on the map, (either a text file, with lat lon and information ?). Let us give him a range of map markers to choose from. He can easily hang around through the interface and select the styles and themes of pop ups based on several events.

Details

To put things more precisely:

  • An intuitive interface
  • The user should be able to select the area of the map to be displayed
  • Select Zoom levels from a drop down
  • Select Map view, renders etc.
  • Give them a wide range of marker icons to choose.
  • Import a text file with Lat, Lon and information. (to show pop ups.)
  • Print the map at a particular scale.
  • Event handling (eg. Mouse clicks)
  • Draw points and shapes and share the maps through online platforms like github (Please comment)
  • (Please add/comment)

Technical Issues

Most people stay back from OpenStreetMap for use with their projects because representing a fairly simple map requires good understanding of OpenLayers and Java Scripts, which they do not need to bother while using other services.

Good understanding of OpenLayers API and Java Script. Structuring the user input of data to be represented on the map. --Sajjad 16:56, 14 March 2010 (IST)

People

Submitter: Sajjad

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Fjbehr 09:36, 9 April 2010 (UTC): AFAIK there exists already a solution which covers most of the functionalities (without printing). I can not find the resource / URI at the moment. In addition in SUAS MapServer a similar mashup is integrated to visualize the data uploaded to the WMS mapserver.

Search

Provide geographically relevant spelling suggestions

Details

The current OSM Search (Nomniatim) suffers from not currently providing spelling and alternative word suggestions for search queries. This project would be to find a practical way (taking in to account response time and resource requirements) to generate geographically relevant suggestions for a word or phrase. This problem is made significantly more difficult by the large size of the data set and the need for full multi-language support which renders such simple implementations as indexing by double metaphone impractical.

Technical Issues

The hope would be to implement this within the context of adding this feature to Nominatim and as such a preferred implementation would be based around postgresql.

People

Submitter: Twain 12:46, 12 March 2010 (UTC)

Possible Mentors: Brian Quinion

OSM Comments

Other Projects

Shapefile Conversion Web App / Webservice

Objectives

As OpenStreetMap grows, more and more data is being imported from ESRI Shapefile (.shp) format. Although there are a number of command line tools to facilitate the conversion from shapefile to .osm format, however no easy, repeatable web-based solution exists. This should be a) a webservice together with a web app that uses this.

Technical Issues

A user should upload a shapefile to the application. Then, based on the geometry of the shapefile and the data types and fields of the attribute data the user could be presented with a set of modifiable rules for conversion should be generated. Finally, the conversion to .osm format should occur.
Key points would be geometry conversion (point, polygon, line), and the rules for conversion (i.e. for the field "build_name" gives tag k=v "name = value", or for "companyId" field map that to the triple tag "company:ref = value".
Most of the heavy lifting has been done there are existing tools that you can work from. See Import/Shapefile for example. --Chippy 18:56, 13 February 2010 (UTC)

People

Submitter: --Submitter name--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Shapefile Export Web App / Webservice

Objectives

Shapefile export for a selected bbox. Aim towards integration with the Export tab on osm.org.

Technical Issues

People

Submitter: --Submitter name--

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Incorporation of Traffic Information and OpenStreetMap data

Details

Objectives
  • Extend or supplement the OpenStreetMap applications to be able to gather traffic information and similar event data.
  • Allow the fusion of existing traffic information sources with user generated data to improve the overall quality.
  • Development of sophisticated methods to enter and edit traffic information as a community. (web client prototype)
  • Provide a easy to use application interface.
  • Provide a solid export service (basic traffic information service) to allow external application to use the gathered data.
  • Use existing standards for data exchange
  • existing scientific and engeneering -work on collecting and referencing traffic obstacles onto OSM can be leveraged
Technical Issues

The biggest challenge is to build a very dynamic dataset (traffic information pool) upon a dynamic dataset like the openstreetmap data.
So the first step is to develop sophisticated methods to make this work. Therefor a notification system, which observes changes in the openstreetmap data set (using the history) and looks for complication with the existing traffic information data, is needed.
If this complication cannot be solved by a automatism based on rules, the community is informed about the status and has the possibility to approve or fix the issue.
To allow external traffic information sources to be integrated in the traffic information pool, transformation from the originating reference system (e.g. TMC Location Code Table) to OpenStreetMap internal reference system (which are the identifiers of the way objects) are necessary.
To gather traffic information using existing standards in this field, the mentioned transformation has to work also the other way round (e.g. OpenStreetMap reference to TMC). The data model of the traffic information pool is designed by using ontologies to achieve long-life sophisticated date model with a high grade of flexibility.
Another import issue are the tools, mechanism and media channels to allow the community to enter and adapt traffic information. For this purpose multiple ways of geolocation are apropriate. One possible such tool is a dynamically updated graph for real time routing using the pgrouting engine or an existing OSM routing application. This allows the user to enter just two points to define the area of impact.
To achieve a high grade of detail and precision, events can be located on ways using linear reference (e.g. way 234234 from 10% to 20%). Of course traffic information is usually not gathered while sitting at home in front of the computer - therefor more suitable manual and semi-automatic method of reporting an event have to be developed.
One possible part of this project could be the integration of a telephone- SMS Server, where people have the possibility to report events while observing it. Users which are in front of the computer, have the possibility to listen to the reported voice data and enter according to its content the traffic event into the system.
This projects is developed as an separate application to the existing openstreetmap applications. But during the concept and development phase it is planned to make the different applications as compatible as possible. Thus allowing an integration in the future. For this purpose the same or compatible development tools and software components should be used.

People

Submitter: User:peter_wien

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

OSM Comments

Add your comments here. Use four tildes to mark your comments.

libosmscout improvements

Objectives

libosmscout (see http://libosmscout.sf.net) bundles *.osm file parsing, preprocessing, map drawing and routing components in a reusable library lowering barriers to work with OSM data and thus allowing easier start of OSM data based applications. It can also act as test bet for routing algorithms, drawing paper maps.

I would suggest improvement by a student in the following areas

Routing - APIs, Profiles and algorithm

Routing should be based on profiles. A profile defines, how fast the routable object (a car, a bus, a bicycle) can travel under which conditions on ways with given criteria.

libosmsocut currently has only a simple routing aproach. It uses street types as simple profile filter and A* als routing algorithm. A more sofisticated profile definition mechanism is required. The API to the routing code also needs improvements, to better support profile definition and plugable routing implementations. And finally the code to post process a route (a list of visited nodes) into a readable format could be improved (post processing includes transforming a list of node sand ways into descriptive instructions like "second street, right, pass post offcie..."). Task would be to define a extendable API for access to routing functionalities, improve the data preprocessor to extent current way information with data relevant for profile based routing. The existing A* implementation needs general performance improvements and support for profile based routing. Also the implementation of at least another algorithm would be nice (A* is optimal but not very fast since it visits too much nodes).

Map drawing

libomscout already has medium quality code for drawing maps. Nevertheless there are some areas that require improvement.

  • Abstraction of the drawing backend (currently cairo) to support other backends like Qt or file exports.
  • Improved placing of labels
  • Support for coastline
  • Better order of primitive drawing
  • Better configuration of styles (possibly changing the style definition format from XML to soemthing more readable or something used by existing applications)
  • Support for getting information about drawn elements based on the position on the map

Technical Issues

libosmscout is design to work for devices with medium CPU and memory capabilities like mobile devices. Thus the speed of the used algorithms and codes is essential. Its internal database must be fit to access data as fast a s possible. This especially true for routing where a huge number of ways is inspected. Also profile based routing is based on a number of additional tag value based data. This data must be extracted from the original *.osm file, a common format must be found and the data must be stored in a compact way. Map drawing speed is also essential. Mathematical operations and calls to the graphic engine must be optimized for speed and memory usage.

People

Submitter: User:Framstag

Possible Mentors: User:Framstag


OSM Comments

Add your comments here. Use four tildes to mark your comments.

Test suite

Objectives

During my work on libosmscout I had the (obvious) idea to test the various implementation aspect of my library against or (or multiple) defined *.osm files. I would assume that other applications and tools might also benefit from an existing test suite in sum raising the quality of a lot of OSM applications.

This would have included testing for functionality like rendering things like bridges, tunnels, layers and symbols but also routing correctly in respect of turn restrictions, maxspeed, cross border navigation...

For this one or multiple syntetic *.osm file(s) would be optimal, that includes all these features in a stable way (ids of nodes, ways, areas do not change, feature do not disapear or reapear somwhere else).

Details

Work would be split into a number of steps:

  • Collecting the most important features to test (ask the community)
  • Collection existing test suites (gosmore and osmarender already seem to have test suites)
  • Defining an abstract test suite by categorizing these features and defining small abstract test scenarious.
  • Design of an environment that allows getting and changing the data, and possibly also not only offers *.osm files but also API instances based on these data
  • Documentation of environment and change processes
  • Creation of actual data files

Note, that not all steps require develpment, in fact the development part is possibly very low, so this might be a problem to get it accepted. Nevertheless this would be possibly of great help for a huge number of existing OSM developers and IMHO testing is a huge and underestimated part of software development.

People

Submitter: User:Framstag

Possible Mentors:

OSM Comments

Add your comments here. Use four tildes to mark your comments.

Waze Integration

Waze is a brilliant app for mobiles which runs on building maps on the phone and track real time data based upon the community updation and my idea is that we connect OSM to waze and start developing waze as a front end and OSM as a backend.As it is opensourced,it isnt really hard to integrate and smartphones are the future.

People

Submitter: User:adivik2000

OSM Comments

This sounds like an interesting idea - could use OSM as the base map, and traffic information from Waze. Specific objectives will need to be defined to turn this into a project proposal though, and it will be necessary to check that there are no licensing issues that would cause the project trouble. Grahamjones 07:38, 24 March 2010 (UTC)

It is very likely that there will be licensing troubles with such a project, as Waze has in the past repeatedly stated in response to any question about OSM integration, that their business model is built upon owning the map data their users create and restrictively licensing it to other companies. This is not compatible with the fundamental idea behind OpenStreetMap to create free as in freedom map data available to everyone for anything. So unless something has changed recently with respect to Waze's intentions, I don't see how a direct integration between Waze and OSM can work. But at the minimum, it needs very careful research beforehand to ensure licensing issue aren't going to kill the project. Creating a system to start OpenTrafficMap however might work. amm 24 March 2010

Yep. Waze integration can never happen. Despite being collected by a volunteer community, waze data is a "copyright. all rights reserved" closed dataset. This is verging on unethical in my opinion, and is something the tech community should rally against. We could make a wiki page about Waze which look very similar to our page about Google Map Maker -- Harry Wood 15:39, 29 September 2012 (BST)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Google_Summer_of_Code/2010/Project_Ideas&oldid=1634168"