Yes, I am aware of these buttons. Do you mean that we do Ctrl+S frequently in order to do partial saves? I feel this might allow for greater chance for conflicts to occur rather than uploading frequently.
On Sat, Jan 20, 2018 at 2:59 AM, althio <althio.fo...@gmail.com> wrote: > Hi Gaurav, > > In the row of buttons, the first two are "Open" and "Save": these actions > are for files locally on your computer. > Third and fourth buttons are "Download" and "Upload", commonly used to > interact with OSM servers. > > -- althio > > On Jan 19, 2018 10:29 AM, "Gaurav Thapa" <gthapa.w...@gmail.com> wrote: > > > > Hi Michael, > > Could you tell me what buttons are used in JOSM for partial saves? Here > in Nepal we frequently upload changes as internet is intermittent this > feature would be greatly beneficial for us all. > > > > Regards, > > Gaurav > > > > On Fri, Jan 19, 2018 at 1:13 PM, Michael Collinson <m...@ayeltd.biz> > wrote: > >> > >> Hi Micah, > >> > >> I think you came up with a good answer to your conundrum in an earlier > post in this thread: Don't explain what an optimal changeset IS, explain > what it is NOT: > >> > >> Something like: > >> > >> "It helps other contributors understand your edits if you group what > you are doing in a local area into one changeset. For example, if you are > creating the outlines of 20 buildings, group them into one changeset. On > the other hand, if you are adding 3 POIs, (points of interest), that are > 1000 km apart in different countries, then it is more useful to put them > into 3 changesets. Of course, if you are creating the outlines of 1,000 > buildings in your town, you do not have to do them all at once! > >> > >> If you worried about losing your data, our data editor software allows > you to make incremental saves to the OSM server as you go along. iD does > this automatically. Potlatch and JOSM have buttons that allow you to save > partial work into a changeset and then keep adding to it until you are > done." > >> > >> [This could probably be improved for readability by non-native English > speakers. And the editor text should be fact checked, I am a die-hard > Potlatch user.] > >> > >> > >> Mike > >> > >> (first post for a long, long time) > >> > >> > >> On 1/17/18 4:13 PM, Micah Brzozowski wrote: > >>> > >>> Certainly I am not intending to change the community and require every > mapper to comply. If you're an experienced mapper, you're fine. > >>> > >>> I mean new users, who are not yet integrated with the community. Their > work should be checked thoroughly (in Achavi, osmcha...). All novices make > mistakes, after all. Better to give them good habits. By extension, smaller > number of changeset will lead to less recycling of same changeset comments. > >>> > >>> I made this thread because I found it difficult to convey what is best > practice in short form in changeset comments. > >>> > >>> Maybe I should simplify things when explaining to them? No need to > tell all the conventions, just what is a good start - but hoping it won't > backfire ;) > >>> > >>> 17.01.2018 3:35 PM "Imre Samu" <pella.s...@gmail.com> napisał(a): > >>>> > >>>> > one changeset per building, repeated 20 times > >>>> > >>>> my typical use case: House numbering on the street: push the > numbers & forget & go to the next house ( fast feedback loop vs. Delayed > gratification ) > >>>> - sometimes the mobil app is crashing, and I don't want to go back > 100m to re-enter - the last 5-10 numbers > >>>> > >>>> > >>>> > Obviously this makes them PITA to review quickly in Achavi or > whatever tool you use. > >>>> > >>>> imho: it is easier to group the changeset on the reviewer side : by > user + by hour ( group by user, hour ) than change the community. > >>>> > >>>> Imre > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> 2018-01-17 15:13 GMT+01:00 Michał Brzozowski <www.ha...@gmail.com>: > >>>>> > >>>>> Certainly not: > >>>>> - one changeset per building, repeated 20 times > >>>>> - one changeset for 3 POIs that are 1000 km apart in different > countries > >>>>> > >>>>> These are real world examples. In the latter Achavi can often refuse > to run. > >>>>> > >>>>> That's also why I asked ;-) It's not that easy to formulate the > answer what is reasonable to include in a changeset. > >>>>> > >>>>> Michał > >>>>> > >>>>> 17.01.2018 2:54 PM "Tobias Zwick" <o...@westnordost.de> napisał(a): > >>>>>> > >>>>>> So, what is the optimal changeset size, and why? > >>>>>> > >>>>>> Tobias > >>>>>> > >>>>>> On 17/01/2018 14:26, Michał Brzozowski wrote: > >>>>>> > Many new users have a habit of e.g. sending one or few objects per > >>>>>> > changeset, resulting in a dozen or even more changesets per day. > >>>>>> > Obviously this makes them PITA to review quickly in Achavi or > whatever > >>>>>> > tool you use. > >>>>>> > > >>>>>> > This habit is probably caused by non-knowledge of how auto-save > works in > >>>>>> > iD (which makes the work reasonably secure), as well as just not > knowing > >>>>>> > better thus forming their own judgement. > >>>>>> > > >>>>>> > How should we teach about optimal changeset size? This is quite > tricky - > >>>>>> > how we would define it? > >>>>>> > > >>>>>> > Can the iD nudge users towards better practice? (Linking to Good > >>>>>> > changeset comments wiki page would be useful as well) > >>>>>> > > >>>>>> > Michał > >>>>>> > > >>>>>> > > >>>>>> > _______________________________________________ > >>>>>> > talk mailing list > >>>>>> > talk@openstreetmap.org > >>>>>> > https://lists.openstreetmap.org/listinfo/talk > >>>>>> > > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> talk mailing list > >>>>>> talk@openstreetmap.org > >>>>>> https://lists.openstreetmap.org/listinfo/talk > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> talk mailing list > >>>>> talk@openstreetmap.org > >>>>> https://lists.openstreetmap.org/listinfo/talk > >>>>> > >>>> > >>> > >>> > >>> > >>> _______________________________________________ talk mailing list > talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk > >> > >> > >> > >> _______________________________________________ > >> talk mailing list > >> talk@openstreetmap.org > >> https://lists.openstreetmap.org/listinfo/talk > >> > > > > > > > > -- > > Gaurav Thapa > > Project Manager > > Secondary Cities Pokhara Project > > Kathmandu Living Labs > > > > _______________________________________________ > > talk mailing list > > talk@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk > > > -- Gaurav Thapa Project Manager Secondary Cities Pokhara Project Kathmandu Living Labs
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk