Re: [OSM-dev] For Using OpenStreetMp Data in Our Web Application for Flex 3.4
Am 2013-01-23 07:56, schrieb Hari Dimes: 1) Can we Embed openstreetmap in out flex 3.4 web application? Yes, embedding in any kind of web application is possible. Most libraries just require adding a JavaScript and making appropriate changes to the HTML. 2) If We Can embed OpenstreetMap in Out Application Than how? You will need to use a library like Leaflet and a tile server that allows commercial usage. Alternatively, you can set up your own tile server. 3) Do We Need Any License for Using Openstreetmap You do not need to pay or register for the data, because the OSM data are available under a free license. You do need, however, to follow the conditions of the license (the most important being crediting the source). You will also need to follow the license for the tiles and the Terms of Use for your tile server. http://www.openstreetmap.org/copyright/en Can we know the features supported by OpenstreetMap? You seem to be confusing OpenStreetMap, a project that collects map *data* with libraries that display said data. OpenStreetMap just provides very detailed map data. The library will then display markers etc. A library that you could use would be e.g. http://leafletjs.com/ Adding Markers This is supported by Leaflet (and nearly any other library). Note that OpenStreetMap is a community-driven project, not a commercial product. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-10-01 09:28, schrieb andrewg_oz: Does anyone else think the OSM API URL should be moved to the new Advanced preferences? In theory, yes. However, I think it is better to keep it easily available to quickly switch between the official OSM API and a custom one, so I intentionally kept it in the main menu. This makes it easier for users who use Vespucci to edit a custom map to quickly return to the OSM server to contribute a change to the official map. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-10-01 09:04, schrieb andrewg_oz: Still thinking about presets. I chose the heart because the presets remind of favourites, which are often represented with a heart. The official favourites icon is a star on Android, but I wouldn't suggest that. What about the document icon (though that usually means new) or a stamp icon that would need to be created? Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-10-01 08:16, schrieb andrewg_oz: 2. I think I'd prefer the undo/redo icons looked the same as the undo icon we already use in the action bar. Keeps the UI consistent. Just mirror for redo (like you've done with the arrow). I tried that first, but changed it to the custom arrow once I noticed the original icon is too large, does not properly align with the text and enlarges the fields. With your cropped version, these problems are less strong, so I think its OK now. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Hi, I have now made and committed the following changes. - Add Advanced Preferences (and move some stuff there) - Add pref to disable context menu in unnecessary cases (default: enabled = show always) - Add heuristics for context menu (to always show it when really necessary). If the above-mentioned pref is unset, it basically works like this: Get the list of touched objects. If there are OSMBugs, always show. If there are no nodes but multiple ways, always show. If there is at least one node, then the nearest node is considered to be clicked, UNLESS this node has another node *really* close to it (not to the click area). This ensures that exactly overlapping nodes and ways always bring up the context menu, while other cases can be handled quickly. (Way tolerance is low enough so it doesn't cause false hits.) - Sort context menu entries by distance to click (nodes by distance first, then ways by distance) - Undo menu: Add background colors (black/white) and icons properly I now always set background and foreground color. The problem before was that I only set one of them and/or only in one case, I think. I also added custom-made greyscale icons. Feel free to remove the icons if they suck/eat too much space or remove the coloring if it causes problems (I think it shouldn't this time). Color has the big plus over icons that it a) doesn't need space and b) is easier to notice than small icons. - Tag editor: Changed X icon size to match editor rows, force minimum text field size The text fields were REALLY small on my device, and the X was too large. Indeed, the spacing between the fields was the X being larger than the text fields. I gave the text fields a minimum height and a bottom border to fix this, and shrunk the X so it is now aligned. - Tag editor: Set autosuggest dropdown spacing to minimum text field size - I chose to use 36dp as the height of one dropdown item (not counting the spacers). This is already more than the text field size on my device, which is 36dp *including* the spacers (and was even smaller before I introduced the minHeight). If the fields and X are big enough to hit, the autocomplete is too. If the autocomplete is too small, we need to also enlarge the fields (in my tests, I didn't have trouble hitting them correctly, though). I suspect the field height could be device/style specific. I will test the entire application on a Galaxy Ace (small low-res screen with Samsung UI) as soon as I can. If it looks and works OK there and on the Galaxy Nexus, it will probably be good for everything. We need to check the ActionBar in the action modes and the tag editor on such a device. Forcing menu items to appear using showAsAction=always might cause trouble if they don't fit, and if menu items with icons overflow, it could be possible that it will be white icon on white background again. (I fixed this for the main action bar by replacing the transparent white with a non-transparent gray that will look the same on the actionbar, but will be at least a bit visible on white backgrounds as offered by overflow menu of the Samsung UI). I did NOT make any changes to the content of the autosuggest (i.e. re-add the duplicates or move the corresponding entries to top), so we currently have a plain alphabetic list. I would like to hear some more opinions on this if possible. Should we maybe remove the distinction between recommended and mandatory tags and add them all when applying a preset? Currently, recommended tags are more or less invisible to the user, so we should do *something*. Oh, and I just noticed that I forgot to update the appname.xml, but I am not the first one. Should we maybe put a $Rev: $ SVN tag in there for now? The dollar signs look nasty but it makes sure it's always up to date. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Feedback for Vespucci-dev
Am 2012-09-24 14:34, schrieb andrewg_oz: It's interesting. The one thing I couldn't stand about the original EasyEdit was that it didn't have a context menu. I found EasyEdit unusable and didn't use it until I enabled support. For me, it is exactly the other way around... not getting the context menu was a major plus of the EasyEdit mode. Is it possible that this strongly depends not only on personal preference (e.g. the zoom level at which one usually works), but maybe also on the device that is being used? I have never had a problem to select exactly the object I wanted. Sometimes, the context menu makes matters significantly worse - for example, I have a Seckbacher Landstraße subway station (node) below a road called Seckbacher Landstraße. Almost as unhelpful is offering me a choice between Node #4316872632 and Node #5691872334 (random numbers here). I'd rather have to tap a second time to hit the correct node than having this choice. I would at least like to have a regular preference in the preference menu, if you think fast toggling of it is unnecessary. Please also consider devices like the Galaxy Note, where a stylus can optionally be used for input. That is pretty precise, I think. There are also Android-based tablet/netbook combos that use trackpads in addition to a touch interface. We could also add an Advanced options button to the main pref editor and hide everything behind that. Of course, I am willing to do the work required for this, this is not a I have an idea but you do the work kind of thing. What about these options: - Always (default) - current behavior - Never - what was implemented before - Intelligent - only if nodes are extremely close (e.g. two nodes in the exact same place) OR if no node is touched, but more than one way is. Regarding the undo colouring, the problem is that on some devices (eg my Desire Z), the undo/redo list wasn't showing up different colours, but more importantly, was showing up light grey text on a white background - almost unreadable! That could possibly be fixed by hardcoding both background and foreground colors for both undo and redo items. However, this: is to use undo/redo icons next to each item. I thought about doing that, but haven't quite gotten around to it just yet. sounds like a good idea too. I would suggest a forward and backward arrow with different colors to make it easy to see the difference at the first glance. You choose, I implement? Regarding autocomplete heights, yes that was me! :-) I guess I tend to prefer default UI wherever possible, based on the assumption it was designed that way for a reason. Consistency (with the OS, other apps) is also good. Android probably defaults to relatively high lines to make fingertip control easier. I understand both things, however, seeing only four autosuggest entries on my Galaxy Nexus with a pretty large 720p/XHDPI screen convinced me to slightly reduce the height. The decision is yours, if you want I could also make it configurable. Regarding tag ordering, I can see the value of most important tags first. The question is how to define most important. It sounds like it could be a constant maintenance effort! The most important tag selection is based on the preset, i.e. does not require any separate maintenance. If a preset has been selected in the current tageditor instance, that one is used, otherwise the one that best matches existing tags is used. Preset items can have mandatory and optional tags. All mandatory tags are added to the tag editor, the optional ones are not. Then, all tags (fixed, mandatory and optional) are shown on top of the autosuggest list unless they are already used. In practice, this means that (only) the optional tags show up at the top of autosuggest after applying preset. Without this, the optional tags are never shown/offered. In a way I prefer the certainty of a sorted list. That way I always know where to find a tag. That is why I intentionally put the duplicates in - you can find the tags from the preset on the top, or you may use the alphabetical list below. This is great when you use the suggest menu while the tag field is empty, but I understand it doesn't look well once a part of the tag name is entered. Again, we have three options: a) Original behavior (tags from preset on top, full alphabetical list below) b) current behavior (only alphabetical list) c) Tags from Preset on top, duplicate-free alphabetical list below If we keep the current behavior, the autocompletePresetItem member and all related code should be removed, as the preset item doesn't have any influence on anything. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problem configuring Cgimap for OSM API
Am 2012-08-30 00:03, schrieb Arjen de Korte: I see database name not specified, so something could be wrong there, but also a message Premature end of script headers: map - I don't know what that means. Looks like cgimap doesn't know where to find your database. Did you tell it through some config file or something? If not, try to find out where to set it, and if it isn't yet documented in the wiki (I think it isn't!) please document it. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Random server errors on API (custom install)
Am 2012-08-30 12:01, schrieb Grant Slater: According to this entry: http://wiki.openstreetmap.org/wiki/Talk:The_Rails_Port#Two_problems_I_encountered... It is likely due to a missing (or broken) Gem install. I found that too, however, I don't think it is the solution. I did run gem install builder, but I think it was already installed (as it is required for installation of the rails port). I guess the solution worked for the person in the wiki as visiting the main page (which he probably did after the install and restart) fixes the issue for some time. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problem configuring Cgimap for OSM API
Am 2012-08-31 16:41, schrieb Arjen de Korte: Thanks for your reply. I tried to set the database name by setting the environment variables in /env/environment as described in the README: Do you mean /etc/environment? Did you try rebooting after making the changes? (Probably a restart of something will be sufficient, but a reboot makes sure). Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Problem configuring Cgimap for OSM API
Am 2012-08-31 16:41, schrieb Arjen de Korte: Thanks for your reply. I tried to set the database name by setting the environment variables in /env/environment as described in the README: DB_HOST=localhost DB_NAME=openstreetmap DB_USER=openstreetmap DB_PASS=pass Additionally I would like to note that putting the database password into a global environment variable sounds REALLY dangerous. You should probably set the variables in the server settings. Actually, the example does that (see lighttpd.conf) and there it uses CGIMAP_ instead of DB_ as a prefix. Try that. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Random server errors on API (custom install)
Hi,
when calling the API on a custom server to get some data like this:
http://example.com:3000/api/0.6/map?bbox=8.19,49.83,9.208,50.373
I sometimes get a result, and sometimes I just get a server error (code
500) with the following message:
NameError: uninitialized constant XMLEncoding::UTF_8
However, it seems that hard-reloading the map page
(http://example.com:3000/ in this case) fixes the error for some time.
Restarting the server seems to bring the issue back. Waiting a few hours
seems to do too.
Does anyone have any ideas what can cause this, or how I can help debug
this issue? I could imagine it to have something to do with some XML
library not being properly loaded.
Kind regards,
Jan
Trace:
[2012-08-29 17:21:35.078326 #4084] Started GET
/api/0.6/map?bbox=8.19,49.83,9.208,50.373 for 79.215.131.87 at Wed Aug
29 17:21:35 +0200 2012
[2012-08-29 17:21:35.085673 #4084] Processing by ApiController#map as HTML
[2012-08-29 17:21:35.085835 #4084] Parameters:
{bbox=8.19,49.83,9.208,50.373}
[2012-08-29 17:21:36.022122 #4084] Node Load (5.9ms) SELECT
current_nodes.* FROM current_nodes WHERE current_nodes.visible =
't' AND (( tile BETWEEN 3493262172 AND 3493262175 OR tile BETWEEN
...
OR tile BETWEEN 3493708964 AND 3493708965 ) AND latitude BETWEEN
49830.0 AND 50373.0 AND longitude BETWEEN 8190.0 AND
9208.0) LIMIT 50001
[2012-08-29 17:21:36.027416 #4084] NodeTag Load (0.3ms) SELECT
current_node_tags.* FROM current_node_tags WHERE
(((current_node_tags.node_id = 1)))
[2012-08-29 17:21:36.029373 #4084] API threw unexpected NameError
exception: uninitialized constant XMLEncoding::UTF_8
[2012-08-29 17:21:36.029510 #4084]
/var/openstreetmap/openstreetmap-website/lib/osm.rb:459:in `get_xml_doc'
[2012-08-29 17:21:36.029635 #4084]
/var/openstreetmap/openstreetmap-website/app/controllers/api_controller.rb:145:in
`map'
[2012-08-29 17:21:36.029770 #4084]
/var/lib/gems/1.8/gems/actionpack-3.2.8/lib/action_controller/metal/implicit_render.rb:4:in
`send_action'
[2012-08-29 17:21:36.029894 #4084]
/var/lib/gems/1.8/gems/actionpack-3.2.8/lib/action_controller/metal/implicit_render.rb:4:in
`send_action'
[2012-08-29 17:21:36.030032 #4084]
/var/lib/gems/1.8/gems/actionpack-3.2.8/lib/abstract_controller/base.rb:167:in
`process_action'
...
[2012-08-29 17:21:36.043113 #4084]
/var/lib/passenger-standalone/3.0.17-x86_64-ruby1.8.7-linux-gcc4.4.5-1002/support/helper-scripts/passenger-spawn-server:99
[2012-08-29 17:21:36.044161 #4084] Rendered text template (0.0ms)
[2012-08-29 17:21:36.044718 #4084] Completed 500 Internal Server Error
in 959ms (Views: 0.9ms | ActiveRecord: 6.2ms)
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, I have made one minor fix to the code (reversing ways did not cause the way to be marked for upload). The official deadline is 19:00 UTC. Please note that I do not intend to abandon the project after finishing GSoC - while I probably won't implement major features, I plan to still do small fixes, especially if they apply to the code written by me. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-19 04:35, schrieb andrewg_oz: I've also noticed a small annoyance with the tag editor. The main map activity is using the new action bar, but the tag editor activity is still using the classic Android title bar. With the background transparent it looks a little messy seeing half the action bar of the main activity behind the title bar of the tag editor. Is that something easy to fix? (eg make the tag editor use an action bar too?) Reasonably easy, yes, but given that the absolute deadline is in 22 hours (give or take timezone differences), it is not going to happen as part of GSoC. Gruß Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-19 12:32, schrieb andrewg_oz: 1. After a while the action bar items started disappearing. First the undo and GPS buttons disappeared. If it happened during data uploading, I think the workaround was missing there, so maybe just inserting it fixed everything. I noticed that at least in some cases where the menu gets messed up an exception is thrown due to a call from the wrong thread. I have now removed an overly broad try..catch to ensure this results in a crash and gets immediately noticed, including a nice stack trace to find where the wrong call was made so it can be fixed. If icons continue to disappear despite this, we'll have to remove menu invalidation (and thus dynamic menus) altogether. I have also built the newest version with the current ActionBarSherlock and support library. Please test it thoroughly. 2. In the tag editor, the tag key/value auto complete doesn't seem to be working properly. The key auto-complete seems to be working, but the value auto-complete seems to be missing entirely. (Should also be fixed now, mail went only to the osmeditor list) Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, I have now added the GPL dual-license notice, added a license viewer with a short description of the license situation and attribution. This also means that the preset icons are included in the main APK again, and checked into the repo. The APK is again available at http://www.janschejbal.de/temp/vespucci.apk The license viewer can be opened from the settings menu, as is usual on Android. Unless something is very badly broken, this should be the final version for GSoC, and the gsoc-janschejbal branch should be ready for merging into the trunk. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-16 19:06, schrieb Shaun McDonald: I'm being pedantic about the page it's going, as the page it currently goes to is only the current version. This is a bug, fixed in my working copy (as it was a trivial string change). Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
A new and maybe last development APK was provided at the usual location: http://www.janschejbal.de/temp/vespucci.apk Due to licensing reasons explained on the osmeditor4anroid list, the preset icons have been removed from the package. A separate icon package is available at: http://www.janschejbal.de/temp/vespucci-icons.apk Gruß Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-11 16:19, schrieb Jan Schejbal: Two things remain to be done: Making a decision how to deal with the different license for the preset, and implementing change export (and possibly linking to the help page from within the application). I have now added OsmChange export. If the JOSM format is better for change exports for some reasons, I can change the export format. A Help link was also added, and I have also merged the polish translation that was committed in trunk during my work on the branch. The APK has been updated. As far as I can see, the only thing left to be done before my work is ready for merging into trunk is the decision how to deal with the preset license situation (and any QA you want to do before merging, of course). I have also updated the GSoC project wiki page to show what improvements I made: http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2012/Improvements_to_Vespucci I put a short help text on the Vespucci wiki page and tried to JavaDoc most code that I added. If you need any additional documentation, just tell me. Although the project is not yet completely over, I would already like to thank everyone involved for the great opportunity and the kind support I received. Participating in GSoC with OSM was a lot of fun - thanks! Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-12 22:49, schrieb Paul Norman: I can see advantages to either format. A JOSM format allows you to edit before uploading while a OsmChange format is more portable, but requires command line tools. OsmChange can be imported into JOSM. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-12 22:57, schrieb Ken Guest: Why not export to both formats and let users decide on a case-by-case basis? If there are significant practical benefits and demand for both formats, this is an option. However, if one format suffices (as I said, OsmChange can be imported in JOSM), I would like to avoid stuffing the app with more and more menu options, and writing code that is not necessary. (At the moment, implementing two formats would require a rewrite of some shared code, which supports one export function per class. Nothing big though.) Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-10 12:28, schrieb Marcus Wolschon: Just tried it. Seems to work really fine. :) I can have a look and add missing German translations. I added German and Czech translations for the strings I added. Somebody should check the Czech ones. A new APK is available at http://www.janschejbal.de/temp/vespucci.apk It has: * Proper, osm-compatible GPX export * Support for interrupted/segmented tracks (both for display and GPX export) * A fix for a nasty bug that could cause multiple elements to get the same OsmId. * Translations Some documentation for EasyEdit and the URLs has been provided on the Vespucci wiki page http://wiki.openstreetmap.org/wiki/Vespucci Two things remain to be done: Making a decision how to deal with the different license for the preset, and implementing change export (and possibly linking to the help page from within the application). For the change export, I can use either the OsmChange format http://wiki.openstreetmap.org/wiki/OsmChange, or the JOSM file format http://wiki.openstreetmap.org/wiki/JOSM_file_format - please decide which one I should implement. I checked the license of the template and icons. These are available under the GPLv2/v3, which means we cannot distribute them under the Apache License (which is the license used by Vespucci). In my opinion, we have the following options: - Include a minimalistic preset and allow the full preset do be downloaded to avoid license issues - Consider the preset and icons a separate module only bundled with Vespucci (not part of it), include it in the APK, and put in a note that these parts are GPLv3. (After all, presets are cleanly separated and can be easily loaded at runtime) - If the preset is considered a part of Vespucci, the full package is a derivative work of both Vespucci and the preset and needs to be licensed under the GPLv3. Dual-licensing Vespucci under the GPLv3 in addition to the Apache License is possible, as Apache License programs may be included in GPLv3 programs. The resulting full package would be GPLv3, while the source of Vespucci would still be usable under the Apache License as long as the preset is removed prior to such use. As I am neither a copyright lawyer nor the maintainer of Vespucci, I do not want to make this decision. Please tell me what to do so I can add/delete the appropriate notices/files to/from the repo. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, a new APK is available at the usual location, http://www.janschejbal.de/temp/vespucci.apk This version has a proper undo menu (long-pressing the undo button allows to undo multiple steps and redo steps that were undone), supports way deletion (and will ask you if you want to delete nodes that have no tags and are not part of any other way). Another high-visibilty change is the ability to show node icons on the map. This is disabled by default and is probably most useful with non-default presets and/or custom maps, although it provides reasonable results with the default preset, too. (Note that node icons are not scaled for both performance and visibility reasons. This is intentional.) Orientation changes are now handled without a restart, at least inside Main and TagEditor, improving performance. The tag editor autocomplete and focus behaviour was enhanced in multiple ways and should now be more pleasant to use. If no preset is selected, it will guess the most appropriate one. The missing reload/update preset function was included. All my ToDo markers are now done. As GSoC is coming to an end, I plan to do translation in the next few days. I will also provide documentation in the Wiki on how to use EasyEdit and how Vespucci URLs (for adding presets/APIs) are built. I might also have a look at how difficult it would be to provide a way to export changes and/or gps tracks for use in JOSM. If I forgot anything important, please let me know. Otherwise, I am planning no new features or changes except for the ones described above. Please test the provided APK so I can fix any bugs that I missed during my testing! Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-06-03 09:28, schrieb Simon Poole: Is there a preferred way for reporting issues (except spaming this list)? I just tried it on a 2.2 device and it refuses to start at all (the release version works). I could not reproduce this anymore on a 2.2 emulator. I remember seeing (and fixing) some lint warnings about the API level, so I assume this is fixed now. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-01 09:41, schrieb Peter Wendorff: I assume it's possible to apply several presets to the same object, each adding it's tags Yes. You can apply any number of presets. Combining this with what you describe about Vespucci, I wonder, if Vespucci supports this, too in the autocomplete feature - that more than one preset is used for the autocomplete menus. Currently, no - only the last preset is used, and only immediately after it was applied. Once you close the tag editor, it forgets. However, you can add one preset, add all tags you want, then add the next preset and repeat. I am afraid making it more complex would make it confusing for the user (When/why do tags show on top of autocomplete?) Second question in the same direction: If I add addr:street, and that's part of an address preset - wouldn't it be nice even if I don't use prefix to get the common tag combination as suggested by the prefix description in the autocomplete feature? I consider using the best matching preset if none was manually applied. However, this could again be more confusing than helpful. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, Preset support is now enhanced. When applying a preset: * Fixed tags (i.e. key and value are given) are still added as usual * Non-fixed, non-optional tags (e.g. text or combo tags) are added with the key only. If the user saves without entering a value, it will be removed. * Non-fixed, optional tags are not automatically added, but considered when the autocomplete menu is built The autosuggest now works like this: * automatically triggered once at least letter is entered (a threshold of 0 is NOT supported by android, unfortunately) * Triggered when the user clicks an already-focused input box * Can be hidden by the back key (default behavior) * The key autosuggest menu contains ** First, all keys that apply to the preset that was applied (if any) ** Then, all keys in presets fitting the current node type in alphabetical order (i.e. if a key appears only in presets that can only be applied to nodes, it will not be suggested when a way is being tagged) ** Keys that are already used are NOT offered again * The value autosuggest contains all values, in alphabetical order, that can be applied to the given key An APK will be provided later. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-30 11:25, schrieb Ken Guest: Could Vespucci be added to the Complete action in dialog when a link to some point on the www.openstreetmap.org map is 'clicked' on? Yeah, should be possible using intent filters. However, please note that I will need to focus on implementing existing ideas (optional fields in presets, displaying preset icons) and testing, debugging and enhancing whatever I have already implemented. Please consider putting ideas into the bugtracker so they don't get lost. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, I have rewritten the GPS tracking part to use a Service, allowing tracks to be reliably recorded even when the application is not active. Tracks are now only recorded by user request. The GPS location can be shown or hidden independently from track recording. Recorded tracks are automatically and continuously saved (an 8k buffer from a BufferedWriter and OS buffers apply). GPS location updates are only requested when needed. This means that exitting the app with the home button will disable location updates (if no track is being recorded) to avoid draining the battery. Please note that track uploading support was never implemented, so currently, you cannot get the tracks out of Vespucci. Some additional minor enhancements are included. The code is in the repo. A new APK has been provided at the usual URL. My future priorities are: - implementing Undo - honor optional/non-fixed tags from presets - show icons from presets on map If time allows, saving tracks and changes to XML (and/or uploading tracks) could also be included. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-28 10:08, schrieb Toby Murray: Not sure if this has anything to do with your changes or not but I can no longer use Bing imagery. If I select Bing as the background, Vespucci crashes when I go back to the map. I can confirm that it does happen in my version, and that it does not happen with Vespucci-0.7.0.apk from the download section. The problem is that the constructor of OpenStreetMapTileServer (which is called on the main thread via Main.onStart() - Map.setPrefs() - OpenStreetMapTileServer.get()) attempts to do blocking network I/O (which android does not allow on the main thread). However, it looks like none of the relevant code was changed since the 0.7.0 release. The documentation for the NetworkOnMainThreadException reveals that This is only thrown for applications targeting the Honeycomb SDK or higher. - i.e. there is a programming issue (network access on the main thread) which did go unnoticed until I bumped the Target SDK Version, enabling strict mode. An ugly hack (disabling strict mode) will be provided with the next APK to fix (read: ignore) this issue temporarily, until someone who is more knowledgable about the tile provider code fixes it properly by moving the network I/O off the main thread. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-28 10:13, schrieb winfi...@gmail.com: I have the same issue. I didn't realise it was to Bing though. A new APK has now been uploaded to the usual location. Please note that this does not really fix the underlying issue, just disable the crash Android triggers to alert developers about it. Instead of crashing, a red border around the screen is now shown while the main thread is hanging due to network I/O. The issue might cause application not responding issues in slow networks, and causes the app to take long to start up. Therefor, it probably should be fixed sooner or later by someone knowledgable in the Map tile code. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-25 07:20, schrieb Graham Jones: The UI looks very similar to your previous version, where you have a menu at the top to select move/edit/edit tags modes. Does 'Easy Edit' mode need to be selected somehow? Yes. The new UI comes into play when you select a node or way in EasyEdit mode. It should then show an action mode with options like tag, delete, history, split, merge/join (or a subset, depending on the selected element). History will be shown iff the element has a positive OsmID (i.e. is already uploaded to the server), Split will be shown on ways with 2 nodes, and Join will be shown only if a way is selected that can be merged (i.e. there has to be a second way sharing end nodes and either both need to have the same tags, or one of them must not have any tags). Your tag editing dialog has a Okay and a Revert button. Is 'Revert' the same as 'Cancel' on other UIs (ie close the dialog without saving changes), or does 'Revert' do something else? It restores the tags to what they were when the dialog was opened, but keeps the dialog open. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-25 15:29, schrieb Derick Rethans: Is Undo on your planning? Yes. Appropriate TODO markers informing about the exact data that needs to be saved on each action are already present in the code. I plan to do the following: * Checkpoints are created at appropriate intervals, e.g. before each user-initiated action is actually performed * Every time an element is changed (this includes creation and deletion, iff the element is not yet included in the checkpoint, the current state of the element is stored, including flags indicating if the element is in currentStorage and apiStorage On Undo, a new checkpoint (the redo checkpoint) is created and for each element in the last checkpoint (the undo checkpoint), the current (i.e. changed) state of the element is stored in the redo checkpoint. After this, the state described by the undo checkpoint is restored (adding/deleting elements as required and changing the values of the elements). Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-25 17:30, schrieb Toby Murray: Question: What does the Save button do? I couldn't find any files on the file system after I used it. Maybe I was just looking in the wrong place? Sorry, first reply didnt go to list: I have removed the button, as it only does what the auto-save feature does automatically (and now reliably). Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, I have implemented a number of significant changes, and released a new APK at the usual location, http://www.janschejbal.de/temp/vespucci.apk Changes include: - Context menu is gone from EasyEdit mode, nearest nodes will be picked automatically - Introduced new UI strongly based on action modes - Ways can be single-tapped to select them, or double-tapped for tagging - Selected elements provide an action mode based list of actions, including tagging, deletion, viewing the history (if the node is on the server), splitting ways (for ways with more than two nodes), and merging ways (for ways where a second, mergeable way is available). Two ways can be merged iff they share at least one end node, are not the same way, and either the tags are identical or at least one of the ways has no tags. This UI replaces my suggestion with a separate way management mode, which would have been significantly more work and would be significantly less user-friendly. Deletion of ways is not yet implemented. I plan to include a dialog asking the user wheter to delete the way and keep all nodes, delete the way and all of its nodes (unless they are tagged or part of another way), or cancel. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Useful post-bot visualisation?
Am 2012-07-17 09:48, schrieb Frederik Ramm: However that would not account for stuff deleted by the bot. To highlight that, I would have to access pre-bot information which is also possible. But then again, stuff edited by the bot would vanish from the map once someone else has modified it, whereas stuff that I highlight because it has been deleted by the bot would remain there forever. I think having a static layer showing exactly what the bot deleted would be extremely useful. (Both in terms of nodes/ways deleted, and nodes/ways where tags were deleted.) Stuff last edited by the bot does not seem too useful for me - if the bot deletes a lot of useful information from a node, and then someone adds something small and unrelated, the node would disappear from the list. I think the only proper way would be, as you suggested, some kind of interface where you can manually mark the elements as replaced/fixed, for elements deleted or edited by the bot. Maybe something customized? I don't know how much effort that would require, but it seems rather straightforward (a list of change IDs with associated boolean flags, plus a changelog containing user, timestamp, id and new state). Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, I would like to give a short overview of the changes I made in the last few days. Most of them are related to bugfixes or other behind-the-scenes work: - I have added JavaDoc documentation for the work so far - I assume that I have found and implemented a fix for the random errors/crashes due to a locked cache database - I fixed the rendering of the StorageBox on Android devices with hardware acceleration - I added better state retention when the device is rotated (for example, the currently selected editing mode is properly kept) - I think that I fixed saving of edits and loaded data. This means that these items should not be lost when the application is closed (and then cleared out of the memory by android). GPS track saving will follow, however, I first want to make sure that data saving works properly and modify it to use separate files for downloaded data and edits and only writes them when the storage is dirty (i.e. changes need to be saved). An APK will be released as soon as the saving changes are somewhat tested. At that time, the wiki will also receive an update. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Weird Vespucci issue
Hi, I have a really weird issue with Vespucci: On my Galaxy Nexus with Android 4.0.4, as soon as the storage box (loaded area) does not cover the entire screen, the whole map is greyed out (instead of just the part that is not loaded). It seems as if the canvas.clipRect(rect, Region.Op.DIFFERENCE); completely blacks out the entire clipRect (in Map.java, function paintStorageBox). On another device with Android 2.3.x, the same code works flawlessly. Can anyone with Android 4.x please test if they get the same behavior? Does anyone know this issue, or how it can be fixed? I tried various things, for example: canvas.clipRect(100,100,200,200, Region.Op.REPLACE); canvas.clipRect(150,150,450,250, Region.Op.UNION); Which seemed to result in a single clipRect of 100,100,450,250 on Android 4.0.4, while giving the expected result (two rectangles) on 2.3.x. Is this a known bug (or feature) in Android 4.0.x? Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Weird Vespucci issue
Am 2012-07-16 03:58, schrieb Jan Schejbal: Which seemed to result in a single clipRect of 100,100,450,250 on Android 4.0.4, while giving the expected result (two rectangles) on 2.3.x. Is this a known bug (or feature) in Android 4.0.x? Of course I can google for hours without finding the explaination, but as soon as I send out the mail, I find it: http://android-developers.blogspot.de/2011/03/android-30-hardware-acceleration.html Its a feature, and I'll make a workaround for it. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Building a friendly new editor in JavaScript
Am 2012-07-14 08:15, schrieb Paweł Paprota: Do you think it would make sense to develop this project as a replacement for the map viewer at osm.org front page? I think that client-side JavaScript rendering of maps is currently too slow for mainstream use, even on desktops. It could probably still serve to provide clickable POIs etc. Kind regards Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-07-12 22:43, schrieb Graham Jones: Hi Jan, This is looking very good - much more intuitive than the original interface where you had to press the menu key, and nice easy access to the upload/download feature, which gets used a lot. Thanks! A couple of comments that I think would improve it more: - It is not obvious to me that the little triangle in the menu bar means that it is a drop down menu - the triangle is a long way away from the 'Move' text etc., which makes it look like a separate icon rather than being linked to that text. This is a default thing caused by using the ActionBar interface. I am working on a workaround, but it seems quite difficult. I have an ugly hack, but am looking for a clean solution. I'll either try to create a separate background color for the dropdown, or at least right-aligning the view. - Do we have to have a separate 'Edit' and 'Edit Tags' mode? I spent a little while with it in 'Edit' mode wondering why clicking on a way did not bring up a tag editing dialog - would it be possible to make a long click bring up the tag editor, and a short drag move the node? This corresponds to the original modes that were present before I started with my project. The EasyEdit mode which I created provides such a combined mode as you suggest: tap-and-drag moves a node, double-tap opens the tag editor. The first tap is needed as otherwise it would be nearly impossible to scroll the map in densely-populated areas as soon as you zoom out (every pixel is in the edit radius of a node then). I would suggest to either keep the edit/edit tags modes as they are (for users who want to tag/move without the additional tap) or just remove them. - Actually, now I wonder what the 'move' mode is now - we seem to have three modes that are about editing existing entities - Move, Edit and Edit Tags - simplifying this would really help. I think move means move/scroll the map view without changing anything. We could rename this to read-only or something similar. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-06-18 07:23, schrieb Jan Schejbal: The API with all changes so far can be downloaded at http://www.janschejbal.de/temp/vespucci.apk Sorry, I only managed to fix some small bugs in the last weeks (Repo and APK is updated). I have exams on the 10th and 11th that take more time than expected to learn for. I think that the primary features are implemented, but not yet thoroughly tested or debugged, and will still need some improvements (e.g. auto-suggest tag names/values based on presets). Feedback on the existing functionality would be appreciated. Kind regards Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-06-14 03:07, schrieb Jan Schejbal: An APK will be provided once the preset downloading is at a stage where a working prototype can be created again. Preset downloading now should work (although I only tested it with one preset so far), and preset/API deployment using URLs is now implemented. Vespucci will react to URLs like: osmprefs://?preseturl=http%3A%2F%2Ftextual.ru%2Firs.xml%3Fpresetname=testasdfapiurl=http%3A%2F%2Fmaster.apis.dev.openstreetmap.org%2Fapi%2F0.6%2Fapiname=test4apipreset=http%3A%2F%2Ftextual.ru%2Firs.xml%3Fapiuser=USERNAMEapipass=PASSWORD (Note that this preset file only has presets for open ways. Trying to tag closedways or nodes with this preset will give you an empty list. The API with all changes so far can be downloaded at http://www.janschejbal.de/temp/vespucci.apk Next up: Probably either fixing the buggy saving, or client-side map icons for nodes matching a preset. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, just a short update, as a more complete one with full preset support (i.e. downloading presets including images) is coming soon. I have decided to move all preset work to the tag editor. The preset tag menu does not pop up automatically, but is accessible using a button. This allows Presets to be available in classic mode, too, and opens a way for more features. One of them is a repeat last button, which will set the tags to the last set of tags saved with the editor. Another one is a list of the most recently used presets directly at the bottom of the tag editor. Clicking one of those presets immediately applies it. If a user notices that he broke the tags badly (e.g. by accidentally overwriting them with repeat last), a revert button allows to return to the state present when the editor was opened. Applying a preset only adds tags, never removes them. To change or remove a preset, the user must delete the tags he doesn't want to keep. A convenient button for this is now available next to each editor row. I think that automatically removing tags would not really work. First, a node can have multiple tags, so we cannot automatically remove a preset when a user choses another one. Second, which tags to remove? All? Only the ones matching mandatory fields? I think this is best left to the user to choose, so I provided an easy way to do so and left it at that. An APK will be provided once the preset downloading is at a stage where a working prototype can be created again. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-05-25 19:44, schrieb Jan Schejbal: The next step will probably be implementing menu-based tagging for the EasyEdit mode. A first version of menu-based tagging (using JOSM presets) now exists. Only tagging of newly created nodes/ways/closedways is supported at the moment, and the dialog is just an ugly placeholder. After trying out different variations, I decided to put the tagging dialog at the end of the workflow, after the node or path is created. This not only gives a more natural workflow, but also allows to filter the preset menu: If the user created a node, only presets that can be applied to nodes will be shown. For nodes, this means one click more (after long-pressing to create the node, tap it again), but for ways this means you don't get interrupted by the tagging dialog after creating the first node. The new features do work at this stage, but are not ready for any actual use yet. (The dialog layout still needs to be done, there is a lot of TODOs and un-tagging nodes, changing tags and displaying tagged nodes still needs to be implemented.) To make it easier to notice that a new node has been added (i.e. the long-press was long enough and you can tap the node again if you don't want to make a path), I implemented haptic feedback using the standard APIs. It will follow the global Android setting. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-06-02 17:21, schrieb Jan Schejbal: The new features do work at this stage, but are not ready for any actual use yet. I have now made a proper menu and icon support (icons have NOT been checked into the repository, as the copyright state of the icons is unclear). The icons are meant for bright surfaces, i.e. some may be invisible on the dark surface. As mobile screens have much higher resolutions and need larger buttons (for touching), we should try consider getting alternative, high-res/vector icons for the Vespucci preset (e.g. http://www.sjjb.co.uk/mapicons/contactsheet) An APK is now available at http://www.janschejbal.de/temp/vespucci.apk When testing, please pay special attention to - if your OSM API password is kept - things that are annoying on small devices - device compatibility To switch to EasyEdit mode, use the dropdown in the action bar. The following features are available: - Select existing nodes by tapping them - Move a node by selecting it, then dragging it - Edit or delete a node by selecting it, then tapping it - Edit a way by selecting, then tapping, a node on the way - Create a new node by long-pressing. If you want to create only the node, tap it again to finish node creation, otherwise, you may create a path by tapping somewhere else. Tap the last node again to finish. Once you tap the last node, the tagging menu appears, allowing you to select a tag from the list, which will then be assigned to the node/way you just created. After this, the regular tag editor opens. The other feature you may want to test is multi-API support, available in the server settings. Known issues: - missing localization - tags assigned via the menu not appearing sometimes Some presets don't have any (static) tags There is an old bug that causes an inconsistent internal state, which then affects all tagging including EasyEdit tagging. Re-downloading should fix the issue. - Icons are low-res and some of them are black-on-black - Tag selection menu not appearing when you finish the node/path by using the ActionMode finish button. I will fix this. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Hi, a first API selection system is now available. Multiple APIs can be added, the current login should be preserved (I still need to test this to be sure), switching is possible and will reload the data (after warning the user if unsaved changes exist). I already made successful edits on the dev server using Vespucci. The JOSM preset selection and provisioning via URLs are still missing. Note that an early version of the EasyEdit mode is already implemented. The menu/preset-based tagging is still missing, but basic editing functions are already there (undo is still missing). This means that this development version (branch gsoc-janschejbal, revision 250) should be usable and easier to use than the current official release version. Please feel free to try it out. The next step will probably be implementing menu-based tagging for the EasyEdit mode. As always, any feedback is welcome! Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-05-21 20:00, schrieb Marcus Wolschon: If you don't have any URLs to list, I recommend only an EditText. That's way easier becauser the EditTextPreference already handles it and it does not confuse the user with an empty list. There will be at least one URL in the list by default (the official URL), and additional APIs can be added via the URL handler (see below). I am planning to use the list to accomodate for users who want to both contribute to OSM, and work on a custom map. A use case that I will probably have myself sooner or later: - I am putting up posters and marking their location on a private map using Vespucci with a custom API URL - I notice a building/POI/whatever is wrong/missing in OSM - I save changes, switch APIs, load the OSM data, make a change to OSM, save, and switch back to the private poster map before going to hang the next poster. If I had to enter the full URL to switch back and forth, I would probably not do it for a minor change. Make sure already stored usernames+passwords of people upgrading to this client are kept. This is important. OK, I will. Better to call it JOSM preset as the format is JOSM specific and not part of any OSM api specification. How about custom JOSM presets desciption: Url to custom map element definitions. ? Thanks, I think I will use that. It's a URL. It's content may change at any time (TTL is seldomly set as an HTTP header). How often do you plan to check for updates? I was planning to update only when the user manually requests to do so, in order to make sure the user is not surprised that his presets suddenly changed. An exception is the default preset, which would be included with the application instead of being downloaded from the URL, and thus updated when the application is updated. However, I could also include an automatic update check. On the first start each day, a HTTP GET with If-modified-since could be sent. Iff a valid JOSM preset file is received in response, update and notifiy (toast), otherwise do nothing. To allow users to easily add items, a vespucci: URL handler will be created, allowing something like vespucci:?api=APIURLpreset=XMLURL Who would use such a URL? This is meant to be an easy way to install new presets or APIs. If an organization wants users to use Vespucci to edit their custom map, they can simply tell them click this market link and install the app, then click this link to select our custom map. If someone made an awesome preset, he can make it easy to install for users by simply providing a link on his web page. Otherwise, users would need to select the URL, copy it, open vespucci, go to settings, open the add menu, then adding the URL. Wouldn't it be more important to have things like what kind of element to add/edit or a location as mandatory elements Location sounds like a good idea, I'll probably add it as another optional element. Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-04-26 22:51, schrieb Jan Schejbal: b) allowing the user to select the API URL to use. Sorry for not reporting in for so long. My biometry project for university is finished and will be handed in today, so from now on, I will have enough time for GSoC. For the API selection UI, I plan to implement the following: In Server settings, add another menu item API URL, with a description text You can set an alternate API URL here. Usually should not be changed. Clicking it will open a selection menu, where you can select the server to use from a list (by default: only the official OSM server). There will be a menu item to add additional URLs to the list, long-pressing an existing item will allow the user to edit/delete it. Selecting the item will automatically set the username/password/preset assigned to it, to allow easy switching between profiles. In addition to OSM username and OSM password, there will be another item for OSM preset URL. It will work like the API selection, but the user will be able to enter URLs to XML files with JOSM presets. The preset will be downloaded and cached. A non-deletable default option will be provided for the preset that will be delivered together with Vespucci. To allow users to easily add items, a vespucci: URL handler will be created, allowing something like vespucci:?api=APIURLpreset=XMLURL If you have suggestions regarding this, please let me know. Thanks! Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-04-28 23:10, schrieb Jan Schejbal: I located the cause for the high CPU usage while the app is idle: Updating the compass arrow (which happens quite often) invalidates the entire map (see the sensorListener in Main.java). I'm probably not going to do anything about this, at least not until I am done with my actual task. I made a semi-fix by ensuring the map is only invalidated when the compass has changed by at lease 1 degree. I also got annoyed by a bug in the zooming logic that caused me to get caught in maximum zoom repeatedly, so I fixed it. Other than that, I have had some time, and as I didn't get any negative feedback on the general idea, I have created a prototype of the easy edit mode. For this, I have added long-press support to the VersionedGestureDetector. A long-press happens if a few hunderd milliseconds after the initial touch event, no scaling, dragging or release of the finger occurs. The listener gets informed about this, and can either chose to ignore it (return false), which means the gesture detector does nothing, or handle it (return true), which means the gesture detector will ignore any following up or drag/scale events (until the finger is released and a new touch occurs, of course). I proceeded to putting in a prototype of the easy edit mode. It currently supports creation of nodes (similar to add mode), moving nodes around (similar to movement mode), tagging (similar to tag edit mode) and deletion of nodes (similar to delete mode). It is mostly separated in its own class, which causes some weird long calling chains. The context menu handling is mostly separate. I plan on completely separating it later, and replacing the context menu with something more custom for more flexibility. I will post some mock-ups during this or next week. While this is just a first raw prototype, it should give you an insight into the look and feel of the planned EasyEdit mode. If you find time, you are welcome to have a look at the code and try it out. I appreciate any feedback you can provide. Note that you will need the ActionBarSherlock library to successfully compile the project. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-04-30 23:13, schrieb Graham Jones: I wonder if it could auto download the map data (provided zoomed in far enough), to avoid having to select that separately too? [the newer version may do that - long time since I worked on it). I'll consider it for the additional changes, once the core of the project is done. I don't have an idea yet how to decide when and what to download - just discarding and re-downloading on every move/zoom until the user makes an edit sound very wasteful, and just downloading once (the first time the condition is met) does not seem very useful. Gruß Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Just a short update: I have created a branch called gsoc-janschejbal, where I will be putting all my changes. To get familiar with the project, I implemented ActionBar support and committed it to the branch. Any feedback is welcome, of course. To ensure compatibility with old devices, I used the ActionBarSherlock library (http://actionbarsherlock.com/), which is licensed under the same license as Vespucci. I also added some icons from the official Action Bar Icon Pack by Google, which specifically mentions that it may be freely used. To optimally utilize the limited space on the action bar, I decided to remove the application icon and name. The editing mode is now selectable trough a dropdown (Dropdown navigation), the four remaining menu items are added as actions (submenus stay submenus). The commit also contains two unrelated changes: I bumped MAX_ZOOM_WIDTH again to allow users to easily move between cities and countries, and I added some horrible proof-of-concept code for on-device rendering (which requires the mapsforge library). It really just shows that it is possible, but is done in the most hack-ish way I came up with. I located the cause for the high CPU usage while the app is idle: Updating the compass arrow (which happens quite often) invalidates the entire map (see the sensorListener in Main.java). I'm probably not going to do anything about this, at least not until I am done with my actual task. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [GSoC] Improvements to Vespucci
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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] [GSoC] Improvements to Vespucci
Hi, my name is Jan Schejbal and I would like to thank OSM for accepting my GSoC project proposal. This means that during this summer, I will be making some improvements to Vespucci, the OSM editor for Android. My primary goals are: a) creating an easy editing mode in which tags are set using a menu structure (based on the JOSM presets) and which does not require mode switching for most actions b) allowing the user to select the API URL to use. You can find details about my project on the wiki page: http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2012/Improvements_to_Vespucci Please have a look at subpage describing the proposed easy editing mode. I would appreciate any feedback and suggestions you can provide about it - if you have any wishes, please voice them. Please focus on the user side; the implementation plans will be updated as I look deeper into the code. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GSoC - Improvements to Vespucci
Am 2012-03-24 19:26, schrieb 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. :( 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. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC - Improvements to Vespucci
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 dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
