"Project Layers" or "Scratch Space" Debate

[joewheaton]

We need to decide whether to go with what @nick4rivers used in QRiS as Project Layers or what @joewheaton originally proposed as Scratch Space.

First, what is it. This is the place where you can now import any raster or vector into a QRiS project and have it as 'part of your project" i.e. on disc and in tree, and available in other places and commands from QRiS. The main thing it does is clip using one of the project extents datasets down a layer on importing it. See also #52

Case Against Project Layers

From @joewheaton, project layers seem to me like something that the project creates, and these are really just things we're brining in for either context or to use as a clipped down input for subsequent assessments and mapping.

Case for Scratch Space

I'm not married to the term "scratch space", but I like the idea of it being a space in which you bring in reference layers from other sources and use them as a basis for what we're "mapping" here in "assessments".

What do people (@philipbaileynar or @nick4rivers @nbouwes ) think? Other names? @nick4rivers make your case for and against?

Maybe Reference Layers? That brings up the idea that we really need to be capturing metadata well here.

[philipbaileynar]

1. If this is just a question of naming, I really don't care.
2. The import function might make clipping to project extent optional. i.e. the "Clip to project extent" input is a dropdown that lists all project extent layers with the QRIS project, with an additional item for "None - Retain Original Data Extent".

[joewheaton]

Context Layers was a good suggestion from @nick4rivers

[joewheaton]

Context Layers it is.

[nick4rivers]

Sounds good Joe.

[nbouwes]

I don't have an opinion on this

…

On Thu, Jan 6, 2022 at 2:57 PM Joe Wheaton ***@***.***> wrote: Context Layers was a good suggestion from @nick4rivers <https://github.com/nick4rivers> — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFP5NVW7N7T6RTR5XXRVIFLUUYF5VANCNFSM5LNDBMCQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Nick Bouwes Eco Logical Research, Inc.

[nick4rivers]

'reference layers' and 'context layers' have als been suggested. I like @philipbaileynar 's idea for "None"

[joewheaton]

We already made call on 'reference' vs 'context" @nick4rivers. We went with your Context Layers. We can always edit label later and live with whatever is on disk or in db. I agree with you and @philipbaileynar on the additional option on import for None - Retain Original Data Extent.