[josm-dev] Is the "should upload" logic a little too eager?

[Greg Troxel]

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.

So, I'd suggest that each layer have a property of whether (some) data
was downloaded, and only offer to upload data from layers that both 1)
have had download operations and 2) have had manual editing operations.
(I realize this may require storing metadata for which there is no
convenient place.)

* saved edits case

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).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/josm-dev/attachments/20130101/c1fa7a58/attachment.pgp>