Regarding the saving aspect of it, IMO it needs to be worked out. I've had a couple of users over here already reporting "data loss" with the following scenario: 1. Open his/her project 2. Copies one polygon from a large dataset and pastes is as a new memory layer (very useful feature introduced in QGIS 2.x) 3. Styles the memory layer, and saves the project 4. The next day, when he/she re-opens the project, the polygon is gone
Throughout the above mentioned workflow, there was never _any_ indication that the pasted memory layer would not be saved when saving the project. If QGIS further ease access to memory layers via incorporating the new memory layer function into the core (which I hope its done :) ), and decide against saving across project session, then there must be a UX to deal with that, instead of silently killing the data of the memory layer(s). One way forward would be to have a warning upon closing a project that has non-saveable memory layers to warn the users. That warning should offer for users to save the memory layers onto a proper format (possibly like the missing layer dialog, with a list of all the memory layers and an input to add the saved file location/name). Math On Thu, Sep 25, 2014 at 4:07 AM, Martin Dobias <wonder...@gmail.com> wrote: > Hi Nyall > > On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson <nyall.daw...@gmail.com> > wrote: > > Hi all, > > > > The recent discussion around memory layers in another thread has started > me > > thinking about the best way to expose them more readily to users. > > > > As such, I've opened a pull request which ports Borys Jurgiel's "New > Memory > > Layer" plugin to core (PR #1591). Hopefully this can be merged for 2.6. > It's > > more or less a direct port - I've left it without the ability to specify > > fields at creation time as I believe that field creation would indicate > that > > we are encouraging users to store real data in these layers, which is > > something we should avoid. > > Cool - from time to time it is handy to make a memory layer for some > temporary data and having to use a plugin / python console for the > creation is suboptimal... > > > What I'm thinking though is that we should rename "memory layers" within > the > > UI. The name suggests that they are remembered, and conveys more of a > > permanent feel. > > > > I think that for 2.6 we could rename them to "temporary scratch layers", > and > > then for >2.6 (after we port the memory layer saving plugin/decide on a > > suitable format for saving them) drop the " temporary" part of this > name. So > > they'll be just "scratch layers". > > I like the name "scratch layer" - and I wouldn't mind having it from > 2.6 even without the "temporary" part although there is no saving for > it. (Saving is still a bit controversial for me as we would > inadvertently create another vector file format - unless we would ask > user to save the layer data into one of OGR supported formats or > spatialite DB.) > > Cheers > Martin > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer