[OSM-dev] GSoC - Improvements to Vespucci

[Jan Schejbal]

Hi,
I am considering to apply for a GSoC project to improve the Android OSM
editor "Vespucci".

I am looking to achieve two things:

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 to select
the type of the node. The menu would be optionally structured in
folders, and could contain both node-type POIs and ways. An example
workflow could look like this:

a) User long-presses to mark a location
b) Menu comes up:
============
| Roads |
| POI |
============
c) User selects "Roads", a new Menu comes up
============
| Highway |
| Road |
| Footpath |
============
d) User selects a type, say, footpath, and since this is a way/polyline
type item, he is allowed to place more nodes. He finishes node placement
using an on-screen button. The app creates a way, automatically tagging
it with one or more tags associated with that menu item (e.g.
highway=path). By selecting and editing the path (double-click/tap
maybe?), the user gets the last menu again and can change the type.

The menu structure would be defined as an XML file and could be custom
to the currently active layer/overlay. Which brings me to the second
part of my proposal:

I was unable to find any good editor that would allow easy to use,
collaborative editing of custom map overlays. Such an editor could be
very useful in a number of situations. In emergency situations, such a
map overlay could be used to share information about areas covered by
searches, or casualties found. In planning, this could be used to draw
plans of an area etc. Vespucci would be an ideal base for this: It
already has the necessary editing functionality, the upload API
functions, and the display of the "background" map from various sources.

Thus, the second part of my proposal would be adding an option to select
which map to edit (i.e. which API to use). Instead of editing the real
OSM data, users could edit their custom map, hosted on their custom
OSM-style server, using OSM (or Bing) tiles as the background. Each
custom map would have its own item menu associated - e.g. an emergency
worker on the local "SAR overview" map would be offered to add casualty
and search area markers instead of roads and POIs.

Integrating this into Vespucci would allow the new editor use the large
amount of existing features, and make sure that Vespucci profits from
any improvements.

I was considering to create such an editor for quite some time. The
existing code in Vespucci gives me the means to do it in a reasonable
timeframe, and GSoC would give me the motivation and pressure to
actually do it.

Do you think these ideas would make a good base for a GSoC project
proposal, and would you be interested in having them implemented? Of
course, any feedback and suggestions are more than welcome.

Also, is there any interest in using "offline" background tiles rendered
on the device using the mapsforge-maps library and their compressed
format? I hacked together a quick PoC yesterday, and it doesn't seem too
hard.

Kind regards,
Jan

_______________________________________________
dev mailing list
d...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[Graham Jones]

Jan,
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.

I wonder if it could have a few different interfaces - the existing, quite full featured one
- the intermediate one you suggest
- 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?

A selectable api url sounds fine - will be useful for testing on the dev server if nothing else.

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?

from my phone

[Andrew Gregory]

As someone who uses Vespucci, and has contributed to it in the past, I would welcome *any* contributions. I think the important thing for GSoC is for any work to be relatively small in scope. Vespucci is a bit messy on the inside and may take some time to figure out. :(

--
Andrew

[Jan Schejbal]

I have worked with the Azureus source code before. I don't know how
messy Vespucci is, but it sure is smaller ;-)

After losing a GPS track to what it seems locking and rotating the
device, I think that robust local (auto)save support would be really
nice to have. Probably, an "undo" function would go well with this.

I am really bad at estimating how much effort a task takes, but I could
imagine doing one or more of the following as a GSoC project:

- Local (auto)save function
- Undo function
- Offline background map support (using the mapsforge lib)
- Simple PoI menu (as described in the first mail)
- Layer/custom API support (as described in the first mail)

I would appreciate help with deciding what combination of these would be
a good scope for GSoC, and of course, most useful for OSM.

[Graham Jones]

Hi Jan,

My personal order of preference for the features you suggest would be:

1. Simple Long Click POI Menu - this would be a big step forward for  usability - I think the application has most of the fundamental features that I would use, but it takes too many clicks to do things.   It would be good to write the code so that the contents of the menu can be customised for other uses (ie very specialised simple editors etc.).
2. Auto Save Function - I think I have lost things before, but don't know how.
3. Undo function - Always good in case you make a mistake.
4. Custom API support - this sounds potentially useful, but not something I have a need for at the moment.
5. Offline Background Map - I am not really interested in this because I try to use vespucci when I am out and can look at the real world, so don't need a background map for reference.

In terms of estimating how much effort is required, it really depends on how quickly you manage to get up to speed with the existing code.  This means that the first thing you work on will take most of the time, and the others are likely to be (comparatively) straightforward.

I would recommend writing your application proposal as a 'base project' with maybe a couple of the features you are thinking of, which you can be confident in achieving, and identify the others as potential extensions if it goes smoothly.

Hope that helps.

Graham.

--
Graham Jones

Hartlepool, UK.

[Toby Murray]

As a Vespucci user myself I have a couple of thoughts.

Any kind of save feature should save out to a file that can be read by
JOSM. I always have to go back and clean up my vesupucci edits after I
upload them. Sometimes it is great to be able to upload from the
phone. But sometimes I would rather just take the phone home, load a
file into JOSM and upload correct data on the first attempt. This is
in the issue tracker:
http://code.google.com/p/osmeditor4android/issues/detail?id=83

Also, anyone looking at the code should keep an eye out for this:
http://code.google.com/p/osmeditor4android/issues/detail?id=91

It's a nasty bug that I suspect some people aren't even aware is
affecting their edits. The first time I discovered it, I had been
mapping for over an hour and ended up having to throw most of it away
because my data had been completely corrupted when this bug was
triggered 30 minutes into my session. The only way to spot it is to
double check the tags on every new object you create.

Toby