Re: [josm-dev] Is the "should upload" logic a little too eager?
> From: Toby Murray [mailto:toby.mur...@gmail.com] > Subject: Re: [josm-dev] Is the "should upload" logic a little too eager? > > On Tue, Jan 1, 2013 at 8:18 AM, Greg Troxel wrote: > > > > On exit, JOSM offers to save data to disk when it's modified, and this > > is of course totally fine. It also offers to upload, and I find this > > to be useful sometimes and sometimes troublesome, in two unrelated > ways. > > > > * inspection of not-yet-uploaded data case > > > > Suppose one has a .osm file that's proposed for import, and is > > reviewing it. It seemed natural to open it in josm, and look at it in > > a layer with the existing data in another layer, and imagery. Then, > > after deciding what I thought, I exited JOSM. But, JOSM offered to > > upload the new data. I of course clicked "no, exit anyway", but it > > seems that this prompt could lead to unintended uploads. > > I would strongly advise putting the upload=false flag in any proposed > import file until the moment you are ready to actually upload it. This > will help prevent you or someone else who is reviewing the file from > doing an accidental upload. ogr2osm sets this flag by default. Other > conversion tools should if they aren't already. I believe in some cases it will still prompt the dialog but then when you tell it to upload it suggests that you don't. I've been meaning to run down all the weird cases where JOSM suggests uploading when it shouldn't but haven't had the time. But yes, upload=false is a *very* good idea for files you don't want to accidentally upload. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Is the "should upload" logic a little too eager?
On Tue, Jan 1, 2013 at 8:18 AM, Greg Troxel wrote: > > On exit, JOSM offers to save data to disk when it's modified, and this > is of course totally fine. It also offers to upload, and I find this to > be useful sometimes and sometimes troublesome, in two unrelated ways. > > * inspection of not-yet-uploaded data case > > Suppose one has a .osm file that's proposed for import, and is reviewing > it. It seemed natural to open it in josm, and look at it in a layer > with the existing data in another layer, and imagery. Then, after > deciding what I thought, I exited JOSM. But, JOSM offered to upload the > new data. I of course clicked "no, exit anyway", but it seems that this > prompt could lead to unintended uploads. I would strongly advise putting the upload=false flag in any proposed import file until the moment you are ready to actually upload it. This will help prevent you or someone else who is reviewing the file from doing an accidental upload. ogr2osm sets this flag by default. Other conversion tools should if they aren't already. Toby ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Is the "should upload" logic a little too eager?
On Tue, 1 Jan 2013, Greg Troxel wrote: A while ago, I made edits to an area (in JOSM, entirely normally, not very large, 20 minutes worth of hand editing), and went to upload them. My memory is fuzzy, but I think the upload had trouble, and when I went to exit, I got the "should upload" prompt. So I did (since I knew all the changes were my recent edits). It turns out that the upload happened twice, or at least the db had many objects added by me twice. (I noticed this running the validator over my whole town.) Specific suggestions to avoid this kind of trouble: ** Somehow, when opening a file with un-uploaded changes, show in the command stack at least a representation of what's not yet uploaded. I find that after saving and restarting, that's empty. ** After an upload which does not complete normally, set a flag that requires an "update modified" operation before another upload can happen (and this needs to persist in the file). Unfinished uploads are a known problematic issue, which is not easy to solve. You will find some tickets regarding that in Trac including descriptions why it is not easy. As others already said - bug reporting is better in trac tickets than in this list. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Is the "should upload" logic a little too eager?
I have noticed a bit of weirdness related to this as well. There are two main issues that I have seen in this dialog: 1) The logic to determine when a layer needs uploading seems to mark it as requiring upload very frequently, but then if you cancel out of the dialog and press the upload button manually, it says there are no changes to upload (which is actually correct), so the two systems both seem to have their own logic, with the one in the exit dialog not being as robust as the one on the normal upload button. Re-using the code from the upload button should make the codebase smaller, and would probably fix many of the issues outlined in the previous message. 2) A possible cause of your duplicated objects from the upload can be the result of something I filed a trac ticket about a while back, namely that after you do an upload to a layer that exists on the hard disk, it would be nice to have an option to automatically save the file to disk after the upload happens so that object ID's on new objects get written to disk immediately. More than once (in fact just the other day) I have uploaded something and forgot to save afterward and then after re-opening josm at a later time and doing more work in the area, some objects get uploaded a second time since the file was not saved to disk after the previous successful upload. Putting the "save to disk after upload" option in the upload window on the tab with the "leave changeset open" checkbox seems like a natural place to put it. Obviously this only applies to layers which actually exist on disk, if someone just downloads, edits, and uploads without ever saving then the state of this new checkbox can just be ignored on upload. Here is the trac ticket mentioned in point #2: http://josm.openstreetmap.de/ticket/7487 Regarding the points made about setting flags on layers, I think this is a good idea and would like to see more of these kinds of protections. We currently have upload=false and the previous poster mentioned a couple more that could work similarly. Knowing the source of the data in a layer and how that should be combined with other layers and/or uploaded would make things a lot easier and less error prone for people working with multiple data sources. -AndrewBuck ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev