<p>Jan,<br>
I think adding long click support to vespucci would be a bug imlrovement to the user interface.  I keep checking out the code with a view to trying it, but have never got around to it.</p>
<p>I wonder if it could have a few different interfaces - the existing, quite full featured one<br>
- the intermediate one you suggest<br>
- a very simple one where you can not change geometry but can just edit tags on existing features and add nodes - this could be useful to make it quick to do simple tasks?</p>
<p>A selectable api url sounds fine - will be useful for testing on the dev server if nothing else.</p>
<p>Offline backgound maps are ok,  but need to make sure the whole app can function without internet connection - make sure you can not loose edits if upload fails and you have to leave it a few days - not sure if it deals with that at the moment?<br>
<br></p>
<p>from my phone</p>
<p><blockquote type="cite">On 23 Mar 2012 04:10, "Jan Schejbal" <<a href="mailto:jan.mailinglisten@googlemail.com">jan.mailinglisten@googlemail.com</a>> wrote:<br><br>Hi,<br>
I am considering to apply for a GSoC project to improve the Android OSM<br>
editor "Vespucci".<br>
<br>
I am looking to achieve two things:<br>
<br>
1. An easier editing mode for new users. (This would include Issue 100<br>
in the issue tracker,<br>
<a href="http://code.google.com/p/osmeditor4android/issues/detail?id=100" target="_blank">http://code.google.com/p/osmeditor4android/issues/detail?id=100</a>)<br>
<br>
2. Layer/custom map support to allow users to create their own OSM-based<br>
maps with non-public points of interest<br>
<br>
<br>
My proposal for (1) would be to add another editing mode (in addition to<br>
the "move", "new" etc. modes currently present). A long-press on any<br>
position would create a node, and call up a customizable menu to select<br>
the type of the node. The menu would be optionally structured in<br>
folders, and could contain both node-type POIs and ways. An example<br>
workflow could look like this:<br>
<br>
a) User long-presses to mark a location<br>
b) Menu comes up:<br>
    ============<br>
    | Roads    |<br>
    | POI      |<br>
    ============<br>
c) User selects "Roads", a new Menu comes up<br>
    ============<br>
    | Highway  |<br>
    | Road     |<br>
    | Footpath |<br>
    ============<br>
d) User selects a type, say, footpath, and since this is a way/polyline<br>
type item, he is allowed to place more nodes. He finishes node placement<br>
using an on-screen button. The app creates a way, automatically tagging<br>
it with one or more tags associated with that menu item (e.g.<br>
highway=path). By selecting and editing the path (double-click/tap<br>
maybe?), the user gets the last menu again and can change the type.<br>
<br>
The menu structure would be defined as an XML file and could be custom<br>
to the currently active layer/overlay. Which brings me to the second<br>
part of my proposal:<br>
<br>
I was unable to find any good editor that would allow easy to use,<br>
collaborative editing of custom map overlays. Such an editor could be<br>
very useful in a number of situations. In emergency situations, such a<br>
map overlay could be used to share information about areas covered by<br>
searches, or casualties found. In planning, this could be used to draw<br>
plans of an area etc. Vespucci would be an ideal base for this: It<br>
already has the necessary editing functionality, the upload API<br>
functions, and the display of the "background" map from various sources.<br>
<br>
Thus, the second part of my proposal would be adding an option to select<br>
which map to edit (i.e. which API to use). Instead of editing the real<br>
OSM data, users could edit their custom map, hosted on their custom<br>
OSM-style server, using OSM (or Bing) tiles as the background. Each<br>
custom map would have its own item menu associated - e.g. an emergency<br>
worker on the local "SAR overview" map would be offered to add casualty<br>
and search area markers instead of roads and POIs.<br>
<br>
Integrating this into Vespucci would allow the new editor use the large<br>
amount of existing features, and make sure that Vespucci profits from<br>
any improvements.<br>
<br>
I was considering to create such an editor for quite some time. The<br>
existing code in Vespucci gives me the means to do it in a reasonable<br>
timeframe, and GSoC would give me the motivation and pressure to<br>
actually do it.<br>
<br>
Do you think these ideas would make a good base for a GSoC project<br>
proposal, and would you be interested in having them implemented? Of<br>
course, any feedback and suggestions are more than welcome.<br>
<br>
Also, is there any interest in using "offline" background tiles rendered<br>
on the device using the mapsforge-maps library and their compressed<br>
format? I hacked together a quick PoC yesterday, and it doesn't seem too<br>
hard.<br>
<br>
Kind regards,<br>
Jan<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
</blockquote></p>