€15.000 Funding for Software Development - Proposal
From OpenStreetMap
Contents |
Introduction
NLnet Foundation (NLnet) has granted us, the loosely knitted OpenStreetMap group in the Netherlands (OSM-NL), €15,000 to spend on software development. In order for us to spend it, and in order for NLnet to monitor spendings, the following actions need to be performed:
- define a legal entity to receive and manage the grant (and possible future grants)
- define a project plan to manage all projects
- define software sub-projects requirements and scope
Bimonthly progress reports
Project Plan
We will setup a high level project plan with NLnet within the scope of the software development grant. Agreements with respect to deliverables, go/nogo's and payments should also be implemented in the sub-project plans and contracts.
Milestones:
- Define and grant sub-projects (FEB-MAR 2008)
- propose sub-projects' requirements and scope (OSM-NL)
- review sub-projects by - international - community (OSM wiki, mailing lists, discussion with key Wikipedia people).
- define requests for sub-project proposals
- deadline submission of proposals
- grant sub-projects to best fit proposals
- propose sub-projects' requirements and scope (OSM-NL)
- Implement sub-projects (APR-JUN 2008)
- Setup contracts
- Setup payment schedule
- Setup detailed planning per sub-project with milestones/deliverables
- M1
- M2
- M3
- ...
- Final delivery
- Final payment
- Sub-projects evaluations
- Setup contracts
- Shutdown project (JUL 2008)
- project evaluation
- future plans
Sub-Projects: Requirements and Scope
This project has two main goals:
- To maintain the overall quality of data while maintaining an open architecture.
- To enable broader participation in the free and open map
Side note: These were derived from discussion on talk and within the Dutch chapter. Although the grant was secured by OSM-NL, the development efforts should benefit OpenStreetMap as a whole. In the early project definition phase, some bias towards the specific Dutch situation (in particular the very complete map thanks to AND) and the challenges that situation poses can't be denied.
To reach these goals, the following sub-projects are proposed:
1. Monitoring and Rollback
A system to enable active change monitoring which could incorporate the following components, available to trusted users:
- Simple, nontechnical rollback function for a user definable geographical area. See also Change rollback
- Subscription to a user definable geographical area to be notified of any changes made in this area. The notification system should be user configurable, e.g. immediate for modifications exceeding a certain number of records, periodical digest for minor edits. See also Change monitoring
- Assigning trust level to users, allowing for some blocking and regulating measures against non-behaving users, at the same time allowing for rewarding motivated users.
The proposed budget for design and development of this system is 160 man hours.
2. Mobile Editor
An application running on a mobile platform that enables users to check, correct and augment OSM data in the field. The application could have the following requirements:
- Display of a background map
- Connect to a device-internal or external Bluetooth GPS device
- Show current GPS position on the map
- Save a track log in standard GPX XML format
- User definable track logging interval
- Add extra background layers (file or server based)
- Preload OSM data to enable usage without data connection
- 'Flag' nodes / segments / areas for later review
- Easily edit common metadata, preferably avoiding text entry (using combo boxes / list boxes).
- Make quick location-based notes, optionally voice recordings / photos.
The scope of the mobile editor functionality excludes adding or moving of nodes and segments to ensure maximum ease of use.
The mobile editor should run on as broad a range of devices possible while ensuring maintainability and a fairly quick development cycle.
The proposed budget for design and development of this system is 160 man hours.
3. Map annotation for the rest of us
Currently, actually contributing to the map requires a learning curve that not all are willing or able to ascend. A large body of passive lay users could be activated by implementing an annotation system. This is already actively discussed in the mailing list. Such a system could consist of:
- A web browser application showing the OpenStreetMap data, analogous to the main site.
- The possibility to search for a specific location (city / town name)
- Basic map navigation like on the main site.
- A function to put a pushpin on the map that is linked to an annotation
- Structured, guided annotation creation, possibly using well defined categories.
- Possibility to attach a binary to the annotation (GPX track log, photo)
- Link with monitoring system as described under 1.
The proposed budget for design and development of this system is 120 man hours.
4. Language Tools
A rewritten version of Name Finder. Current version has some limitations, which will have a significant negative impact to OSM abilities for newcomers. The web search should have the following features:
Multiple language support:
- localized versions of objects
Quieries like - "cesta" / "ulica" (Slovenian) - "Rue" (French) - "strasse" (German) - "street" (English) and so on should give the same result.
- "translated" version of names
E.g., in non-latin-based languages it's hard to manually give latinised equivalent for every object, even for streets. It means that English-speaking person, who comes to e.g. Japan and who wants to find some street, will be stuck because he doesn't know hyierogliphs. At the same time in such languages usually exist some rules for "translation" or "latinisation" of names. Automatic usage of such rules when indexing will be good.
- system language based search results.
If a person's operating system is in Slovenian, than the primary language of search results should be Slovenian
- accented characters omission
- pronouncation-based and spellchecking search
In foreign countries sometimes it's hard to distinguish the correct spelling of object name. At the same time some algorithms based on pronouncation similarity like Soundex can give results. The same applies to incorrect spelling of name.
Speed, size and interaction:
- indexation speed based on hourly planet.osm diffs
The indexation process shouldn't be a day long.
- search speed
First search results should be returned within a second or less
- large volumes support
Commercial maps from Garmin or other providers feature millions of POIs. Effective search on such amount of data, including language tools mentioned above, is necessary.
- API
Compete API or just XML response for using search results in external applications and services.
Taking into account all requirements, it's clear that some specific search system should be used instead of writing a new one from scratch. However, any system should be tuned to support map-specific features like lat/lon for "near ..." search and multi-language support, so commercial support even from open-source comminities is needed.
In general, search engines should be:
- open-source - well developed - cross-platform - fast and stable
The candidates are few:
- Lucene or its derivatives.
- ASPseek It's more a web search engine so possibly it doesn't suit the requirements.
General Requirements
General requirements for all sub-projects would include:
- Integration with existing tools, in particular JOSM. Don't start from scratch if that's avoidable.
- Using existing infrastructure and software wherever possible.
- Minimal hardware requirements, especially on the server side.
- Bug fixing and maintenance would have to be ensured, a long term commitment to the deliverables is required.
- All software should be made available under a GNU GPL license
