The project proposal consists of two primary items:

1. An easier editing mode for new users. (This would include Issue 100 in the issue tracker, http://code.google.com/p/osmeditor4android/issues/detail?id=100)

2. Layer/custom map support to allow users to create their own OSM-based maps with non-public points of interest

My proposal for (1) would be to add another editing mode (in addition to the "move", "new" etc. modes currently present). A long-press on any position would create a node, and call up a customizable menu (loaded from XML) to select the type of the node. The menu would be optionally structured in folders, and could contain both node-type POIs and ways. The default menu entries for editing OSM could be taken from the JOSM template menu.

If the user selects a way or area type from the menu, he can add additional nodes, finishing by tapping on the last node added. The way is automatically created, and the tags specified by the menu item are assigned.

If the user selects a POI type, the node is immediately created with the appropriate values.

Tapping an already existing node would select it, allowing the user to move it or tap it again to edit it. Editing means the user will be presented with a menu allowing to chose a different node/way type from the last menu (e.g. turn a post box into a post office, or a street into a footway), delete the item, or edit advanced tags.

For (2), the user would simply specify the API URL to use in the settings menu, possibly selecting it from an XML API endpoint definition file. All data would be fetched from and written to that API (and displayed on the background map). This would allow e.g. a rescue organization to set up an access-controlled server where rescuers could mark areas already searched, or casualties found. To assist such private maps, selecting a different API could load a custom menu config for the "easy editing mode" from the first part of the proposal. E.g. in case of the rescue organization, instead of POIs and roads. the menu would offer casualty and search area markers.

These are the two primary items that I consider to be the main proposal. However, if these are implemented before time is up, I do not want to sit idly and enjoy my quickly finsished project. Instead, I will implement additional features (or fix bugs). I am specifically thinking to implement some of the following:

• Reliable local (auto)saving to prevent data loss, allow off-line usage and possibly editing using JOSM before uploading
• An "Undo" function
• Rendering the background map on the device using the mapsforge library (to enable true offline usage)
• possibly other features as requested or bugfixes from the issue tracker
  

I do not want to fail just because I scoped the proposal too broadly, so I limited the proposal to the two primary items. I expect to be able to do at least one of the additional items. If you would like changes to the scope or main focus of the proposal, I will happily do so.

If allowed, I would prefer to keep documentation limited to user workflows and only a high-level overview (where/how to integrate new and existing code) code-wise. However, if required, I can present class diagram drafts etc. beforehand.

All plans will be discussed on osm-dev so the community can make sure the result will be what OSM and the users really want.

Schedule for project completion:

I expect to be able to fully familiarize myself with the existing code and do all required research during the four-week "Community Bonding Period". Within the first week of the community bonding period, I will present a detailed specification of the suggested menu structure, work flow, and a high-level overview of the approach I want to take code-wise (e.g. where I want to connect the new parts to the existing code). In the following 1-2 weeks, I will discuss this with the community on the osm-dev mailing list and adapt the plan accordingly. If allowed, I might already start on some coding.

I would like to have at least the menu-based POI feature implemented in a first version within the first two-three weeks, and having at least alpha-quality versions of both primary features by end of June. I am bad at estimating project times, but I consider this a schedule that should be easy to meet. Should I be faster, I will implement additional features.

Code of the two primary features that is ready for review should be done by mid-July, allowing time for more testing, enhancements after review, additional features, external documentation if requested and a buffer for unexpected delays. (Ready-for-review includes any in-line documentation including Javadoc.)

Testing will be done continously during development, as code is not "implemented" until it works, and until it isn't tested, it usually does not work. Additional testing will be performed on the finished product, of course.

So, to summarize, these would be the primary milestones:

• April 30 or earlier - present draft for two primary features to community for discussion (includes basic code design)
  
• April 30 to May 14 - plans adapted according to the wishes of the community
• June 4 - (at least) pre-alpha code for menu-based POI feature implemented
  
• June 30 - (at least) alpha code for (at least) both primary features (menu-based POI creation/editing and API selection support) implemented
  
• July 15 - fully implemented, tested, javadoc-documented, ready-for-review code for both primary features; possibly code for additional features
  
• following this: enhancing the code after receiving the review, implementing additional features, more documentation and testing.