[OSM-dev] [GSoC] Improvements to Vespucci

[Jan Schejbal]

Hi Marcus,
thanks for the feedback!

As a side note - should I work on a branch, or fork the repository to a
GitHub repo?

> "tapping the last one twice or closing the way." I would prefer and 
> ActionMode in an ActionBar (consistent with the new UI guidelines)
> and ending that ActionMode finishes drawing the way.

Thanks - I have now looked into the action modes, and they seem like a
perfect way to implement this. I assume bumping the targetApiLevel (not
minApiLevel!) to a rather high value (probably 14) should not be a
problem? To keep the minimum API level low, I would like to use the
ActionBarSherlock compatibility package (http://actionbarsherlock.com/).

ActionBarSherlock is licensed under the Apache license, i.e. we can use it.

Please note that the ActionBar occupies valuable screen space. On
tablets, this doesn't matter, but on phones with small screens, it could.

I managed to successfully run Vespucci with ActionBarSherlock on 2.3.6
and 4.0.4. However, APK size is now around 1 MB due to the lib.


> Also keep in mind that some node of a way may be existing nodes
> of other ways.

I plan on handlig this in the same way this seems to already be handled
- if a tap hits a tolerance circle of an existing node, the existing
node is added to the way. I just need to decide what to do when the
initial long-press hits an existing node. Probably offer to create a new
way from there, extend paths ending there, and split paths going trough
there.


> I'd prefer an undo in case the user accidentally misses the spot he/she
> wanted to tap.

At least for the easy edit mode path editing, I can add that. If time
permits, I may extend it to all edits.


> We should not rely on menus anymore as they are deprecated and completely
> replaced by the ActionBar now. There is no menu button anymore. There is no
> search button anymore.

I can rework the app to use the ActionBar instead of the menu. The only
change that is affected by this is the addition of the easy edit mode to
the mode selection - the rest of the "menus" mentioned in my plans are
context menus.




> What alternative API URLs are there except the main and develop
> -servers of OSM?

Currently, I don't know any. Part of the project is to make it possible
to use such, for information that does not fit into OSM at all.

I got my idea for this project after I could not find a way to create a
shared custom map and edit it on Android. (Google Maps doesn't have such
a feature, so making one based on OSM seemed like a good idea to make
OSM more useful and popular)


> Do you intent a selection or an input field?

For the beginning, probably an input field (defaulting to the official
API of course).

Later, I would like to add a selection, to which entries can be added
using a URI-based interface after user confirmation.


> If at all, we should have that in an "expert" part of the preferences
> and use the OSM server as a hint and as the default if nothing is
> entered to prevent fragmentation of the map.

Yes, I fully agree. The official API will always be the default.

Should I decide to create a (free) "custom map" server, I will make
*very* clear that if your information is relevant to OSM, it is always
preferable to use the official map instead of a custom one. For example,
when someone decides to map surveillance cameras, they should do so in
OSM and not on a custom map. (I know of one such project and have told
them to do it in OSM. If they don't, I'll ask for permission to put the
data into OSM later)

Users who use a custom map and see an error in the official OSM map in
the background will be able to easily switch to the official OSM API,
fix the error, then switch back to their custom map.

Gruß
Jan