search

Riverscapes / pyBRAT

pyBRAT - Beaver Restoration Assessment Tool (Python)
http://brat.riverscapes.xyz
GNU General Public License v3.0
10 stars 10 forks source link

Major Changes to Layer Packages #134

Closed joewheaton closed 5 years ago

joewheaton commented 6 years ago

The layer packages that @banderson1618 have produced have been a huge time saver. They are a great start. This issue post is to start the dialog on changes I want to see made to what we already have. @banderson1618 you can either just work through the video and make changes as I describe, or if something requires more discussion, build its own issue for it.

Here is the layer package updated that I show in videos: https://usuonline.maps.arcgis.com/home/item.html?id=eff3e540db8b4c33a779d683246fe15e

Shout with questions or clarification and rope others in as needed.

banderson1618 commented 6 years ago

This is me responding point by point to the things raised in the video, both so that there's a summary of the points in the video and to ask @joewheaton clarification questions if necessary.

BRAT Symbology Part 1

If there's something I missed, or something I'm misunderstanding, feel free to let me know.

joewheaton commented 6 years ago

Responses to questions in @banderson1618 list :

Should the Context layers be included in the project, like the symbology layers are now? That's the only good way I can think of including them.

I think so, but its possible that they might really slow down loading of the layer package. We should test this and see if that is just my machine. If that is the case, we just leave them out. They shouldn't add any size, but may impact performance. If the later, we just need a help page that explains how to use.

Is there a good resource on avoiding resampling errors in hillshades? I have a fairly rudimentary understanding of the process, so I could easily be doing something wrong.

Yes... some of this comes from reprojecting datasets unwittingly. For more then you ever want to know about this see: http://gcd.riverscapes.xyz/Help/Concepts/data-preparation---best-practices/

The layer package names were brought up to be changed back in #68, and to my knowledge they seem to be working fine. If you're working off of a BRAT run that was done before June, that would explain why the names are still weird. I can send you a layer package if you want an example of the latest and greatest.

I'm pretty sure that I am working off of latest and greatest with this Wyoming run as @Albonicomt just did these in last few weeks. I was not involved in renaming things and that will be in state of flux for a little while as we get input from stakeholders.

I have looked a little bit into how to change if a layer will be checked or unchecked by default, but I haven't had any luck so far. All my layer packages load with all the layers automatically checked. Not sure why yours isn't. Could you have edited it after the fact? Regardless, I'll look into this more, since it is annoying to have to uncheck everything before you do anything with the layer package.

No, it came in like that, but the machine I'm working on is using 10.5... I could test on 10.6.

Do you want us to change the symbology to have a width of 1 instead of 1.5? It was briefly brought up, but it sounded almost like a side note.

As a rule of thumb, yes, but I show specific gradated widths for many of the outputs to emphasize cartographically the part of the layer we are most interested in. So, yes, but keep eye out for specific over-rides in provided layer package and videos.

I'm 90% certain that I can change the order of how things appear in the layer package, so that the hillshade layer goes to the bottom.

Great.

I'll need to make a symbology layer for the hillshade layer to change its brightness, but that shouldn't be hard, just time consuming.

Not mission critical. Maybe split on to its own ticket and leave it in development as scoped, but we won't put a milestone on it for now.

The DA symbology was also updated in #68, as were the names for the rasters.

Again, probably something that @bangen or @wally-mac had input on. Now I'm providing my two-cents (not to say mine are right), and then we'll get other input from our users.

We've had some problems with Vegetation symbology in the past. I'll look into improving it, but it might not be easy.

Understood. It is tricky dealing with raster attribute tables.

Create symbology layers for vegetation that use the guidelines outlined at ~20:00 in the video. I would be concerned about relying on the roads shapefile to have the RTTYP attribute. How ubiquitous is that attribute?

Not sure? Maybe ask @bangen (out until next week)

bangen commented 6 years ago

\Create symbology layers for vegetation that use the guidelines outlined at ~20:00 in the video. I would be concerned about relying on the roads shapefile to have the RTTYP attribute. How ubiquitous is that attribute?

Not sure? Maybe ask @bangen (out until next week)

@banderson1618 We should plan for instances where a user may use a roads input layer that doesn't have that field. Is it possible to have an ifelse statement when you create the roads layer file? If so, you could check if the field 'RTTYP' field exists, and if it doesn't simply apply the roads layer symbology you've used in the past.

banderson1618 commented 6 years ago

@bangen, yeah, that should be doable.

banderson1618 commented 6 years ago

I think so, but its possible that they might really slow down loading of the layer package. We should test this and see if that is just my machine. If that is the case, we just leave them out. They shouldn't add any size, but may impact performance. If the later, we just need a help page that explains how to use.

@joewheaton, I'm not sure that I agree with this statement. Based on my understanding of layer packages, I think that the context layers would add to the size of the file quite a bit. That data has to come from somewhere, and layer packages are self contained (as far as I understand them, at least), so I don't see how you could have context layers in the layer package without them adding to the size of the layer package. There might be a way to get them to pull that data from the internet that I'm unaware of, or I might be misinterpreting your comment.

banderson1618 commented 6 years ago

Also, I found a link that explains the RTTYP attributes. Probably best to stick to that when we're making our symbology. Here's the link: https://www.census.gov/geo/reference/rttyp.html

bangen commented 6 years ago

@banderson1618 Can you please ensure the last three commits are pushed to the master branch?

Albonicomt commented 6 years ago

@joewheaton and @banderson1618, I think the context layer adds quite a bit of lag to the operation. I have noticed on my end, when I add the context layer into the layer package, there is a significant lag in arc. I think the context layer would be better left as a separate or optional LPK.

bangen commented 6 years ago

@banderson1618 I chatted with Wally and he suggested if you need help with making edits to any of the layer files to work with @Albonicomt. Per our conversation earlier, I'll handle changes to the conflict and management model fields, layer files, etc. You should focus on the layer files for the other tools with first priority being changes to the BRAT project and BRAT table tool layers.

banderson1618 commented 6 years ago

Just a thought... would it be better to have the buffers have a fill color, but have a high transparency rating? I've been playing around with it, and it's a bit easier to track, in my opinion. The one draw back is that you don't see exactly where each buffer ends, because they overlap and cover the border lines, but I don't think it's a big issue, personally.

Here's some screenshots, comparing the two effects. The first is 0% transparency, black borders, no fill. The second is at 80% transparency, light grey borders, light blue fill ("Sugilite Sky", technically). @joewheaton, @wally-mac, @bangen, I'd be curious to hear your opinions on this.

nofill

transparentfill

Edit: I just realized that I didn't include a picture with a background that had data. Here's a comparison that has the land use raster in the background, since that's more like a real life use. transparent_w_background nofill_w_background

Albonicomt commented 6 years ago

@banderson1618, I like the transparency. What if you also had the 30m as a light green with 80% transparency as well, that way you can see both if you need.

banderson1618 commented 6 years ago

That's a good idea, @Albonicomt. Here's a screenshot of a quick implemenation of your idea, both with and without the background raster: bothbuffers bothbuffers_background

Albonicomt commented 6 years ago

@banderson1618, that looks sweet. I like it.

banderson1618 commented 6 years ago

Sweet, thanks for your feedback @Albonicomt! I'd still like to get some input from the bosses before we put this on the master branch, but I'll make the changes and push it to the layer_package_changes branch.

wally-mac commented 6 years ago

@banderson1618, I like the symbology that you and @Albonicomt have come up with. I think is it really effective and easy to understand.

banderson1618 commented 6 years ago

Thanks for your feedback, @wally-mac. I'm working with the valley bottom symbology right now. Would it be good to make the valley bottom symbology something similar to the buffer symbology shown above? It seems to me that they serve similar purposes. @joewheaton, your input would also be appreciated.

Albonicomt commented 6 years ago

@banderson1618, I think a transparent Valley bottom is a good idea as well. I'd say a similar transparency at around 80%, but with a solid outline of the VB, so one can see a definitive edge to the VB. What do you think?

banderson1618 commented 6 years ago

@Albonicomt, that sounds good. I'll get some demos going, and upload screenshots once I'm there.

wally-mac commented 6 years ago

Sounds good. Looking forward to checking out what you come up with.

On Mon, Aug 20, 2018 at 11:00 AM Braden Anderson notifications@github.com wrote:

@Albonicomt https://github.com/Albonicomt, that sounds good. I'll get some demos going, and upload screenshots once I'm there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/pyBRAT/issues/134#issuecomment-414388961, or mute the thread https://github.com/notifications/unsubscribe-auth/AU-QUmJdRcmuvbgfi4g3F8lKjaCHm5coks5uSusXgaJpZM4VuXYh .

-- Wally Macfarlane 435.512.1839

banderson1618 commented 6 years ago

Border with some fill: valleybottomdemo

Does this look good to you guys, @wally-mac and @Albonicomt?

We've applied some transparency since I made the buffer symbology (see commit 0e86ef8), which is why the background raster looks different.

bangen commented 6 years ago

@banderson1618 Are you going through Joe's videos while making changes? If not, please do so. If I remember correctly, he wants to see the valley bottom both as a filled, transparent layer and a solid, no fill layer.

banderson1618 commented 6 years ago

@bangen, yes, I know that that's what Joe asked for. The way that the program is set up, that's a bit more inconvenient to do than you'd think. I can do it, but it'll take some time to get the program to a place where it can support creating multiple symbologies for a single input. Maybe 2-3 hours. Not super long, but more time than I think it's worth for just one change, given the amount of changes we want to make.

bangen commented 6 years ago

@banderson1618 Go ahead and work through the other layer changes then circle back and implement Joe's request for the valley bottom.

banderson1618 commented 6 years ago

I've made all of the simple changes that Joe asked for in these videos. By "simple", I mean changes that only required modifying the symbology of existing layers or adding new layers that symbolized attributes that are already being produced.

The changes that I have not made were the following:

wally-mac commented 6 years ago

Nice work @banderson1618! I look forward to seeing what you have come up with.

bangen commented 6 years ago

@joewheaton

This comment is in reference to the mCC_**_Ctand mCC_EX_PT fields. I added the mCC_**_Ct fields to the Comb FIS tool so we're good on that front. I do have some questions about the mCC_EX_PT field and am going to hold off on implementing that until I hear back from you.

My specific questions are: