[Qgis-developer] Memory Layers - some proposals

[Nathan Woodrow]

What about a icon in the legend to note that it it's not going to be saved?

- Nathan

On Thu, Sep 25, 2014 at 3:57 PM, Mathieu Pellerin <nirvn.asia at gmail.com>
wrote:

> Thoughts:
> - I don't think warning should be occurring when creating a memory layer
> (that is when pasting as new layer, when adding the result of a processing
> algorithm as memory layer, or creating a blank memory layer)
> - I don't think the user should be able to disable the warning message
> (which imo should be a dialog with saving shortcuts), the resulting data
> loss is too critical; it's like opening a project with missing layers, qgis
> doesn't (and shouldn't) allow for this dialog to be skipped
> - IMO best to have: a/ a message bar when saving project while in an
> ongoing session, and a missing layer-like warning dialog when closing
> project
> On 25 Sep 2014 12:15, "Denis Rouzaud" <denis.rouzaud at gmail.com> wrote:
>
>>
>> On 25.09.2014 04:02, Mathieu Pellerin wrote:
>>
>>    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).
>>
>> I would be in favor of a warning when first create a memory layer. The
>> warning would say you can't save them except from using a plugin. And,
>> there would be a checkbox "do not display this warning anymore".
>>
>>
>>
>>
>>  Math
>>
>> On Thu, Sep 25, 2014 at 4:07 AM, Martin Dobias <wonder.sk at gmail.com>
>> wrote:
>>
>>> Hi Nyall
>>>
>>> On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson <nyall.dawson at 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 at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>>
>> _______________________________________________
>> Qgis-developer mailing listQgis-developer at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140925/ace23d95/attachment.html>