Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restandardizing Summary Products #180

Closed
Albonicomt opened this issue Sep 27, 2018 · 13 comments
Closed

Restandardizing Summary Products #180

Albonicomt opened this issue Sep 27, 2018 · 13 comments
Labels
discussion Discussion among BRAT developers and power users. duplicate This issue is marked as duplicate to another issue.

Comments

@Albonicomt
Copy link
Contributor

@CHafen and I are working together to create a new standard for Summary Products. We are hoping to create something that improves upon the old Summary Product standard shown below:
san_rafael_rvd_4_18

We want to create something that keeps the summary product simple but easy to distinguish the spatial reference and displays the output summary well. Please share your input as @CHafen and I upload some sample maps over the next few days.

@Albonicomt Albonicomt added the discussion Discussion among BRAT developers and power users. label Sep 27, 2018
@Albonicomt
Copy link
Contributor Author

I think this one, in terms of a perennial network, simplifies the spatial reference a bit, but isn't too complex when it comes to trying to produce a bunch of maps. I have more to share, but I think this is the most refined and simplistic one. Any thoughts? @CHafen
sanrafaelrvd

@Albonicomt
Copy link
Contributor Author

@wally-mac Here is the Github issue I made last week. Here are some examples. I also have a few more Ideas for the charts, and so does @CHafen.

@wally-mac
Copy link
Contributor

I'm adding @joewheaton to the conversation. Joe do you have any input at this point?

Thanks!

@joewheaton
Copy link
Contributor

Hi @CHafen and @Albonicomt. I like the initiative you're taking here. This looks great. A few thoughts:

  • Overall, I would strongly encourage us to think of having a menu of template options to choose from, and we mix and match the details (say on legends, graphs, context layers, line weights), to convey the message we want for any specific map. If we get back to the basics of C's... the most important C is convincing relative to purpose. Context matters... and consistency matters, but we can achieve consistency with a vareity of choices in our family of standards, but we shouldn't put consistency above convincing.
  • On old one, I think we should keep in the rears the option of the 'base' context you have shown on these old style maps (i.e. hillshade for Area of Interest AOI and the roads and such. For some maps, that might be more effective than using imagery and less distracting. So lets not completely throw out that context as an option.
  • On the new one:
    • I really like the new line weights for perennial network. I think we should always show the perennial. Note that we may (depending on what purpose of map is) vary line weights by category to emphasize what we're most interested in.
    • I really prefer the horizontal bar plots to the pie charts. However:
      • I would recommend always making horizontal axis in distance (instead of %) and doing it in a way that shows both miles and kilometers (in same symbology). Keep the percentages at right of each bar as they are great, but redundant if axis is %.
      • I wonder if in some cases (as an option it might make sense to combine the legend and bar plot into one (i.e. align bars just to right of legend categories). This may depend on layout...
      • I wonder if thicker (taller) bars would be distracting or better?
    • I prefer the Arial Narrow instead of Arial. It is a more compact look that takes up less space and lets you see the map... it is still readable.
    • We should still think about what are the most useful place name categories. Here you only show towns. @wally-mac points out that the old basemap stuff chooses some odd things. Our job as cartographers is to draw attention to the context that is most important (e.g. the name of that peak, the name of that mountain range, the name of a river (at a minimum we should be naming the major tribs as these are network maps), name of a valley, etc.
    • I like the road symbology
    • I like the watershed boundary outline. I'm torn about the transparent white in the area of interest. In some cases, where imagery is detailed, it might be helpful like you have it as it lets your eye focus on the symbolized network output and not the aerial imagery. Lets keep this an option.. In other cases, you may not want to obliterate that context in AOI and lighten it elsewhere.
    • We should play with option where we show rest of network really thin and light and see how bad or off that is...

@CHafen
Copy link

CHafen commented Oct 1, 2018

Here are some examples I came up with on Friday, but didn't get them up until now, so I have not yet incorporated @joewheaton comments.
But there is an example of showing the full network as a thin line. I think it looks pretty good with how it is in these figure, but I think with the other context labels that Joe is suggesting (especially names of major river/tribs) it will look messy. But I can add the labels to these figures and see how it looks.

A few things to note:

• Labeling by hand is time intensive. Even without adding the other context labels Joe suggested it took about 3x longer to make these maps than the summary products we were producing. Though if we’re making several maps in the same area (ex. All RCAT and BRAT outputs) I only have to make the layout once per area
• I think the bar charts look nice and read well though they do have some down sides:
o They take 3-4x longer to make per figure than pie chars primarily because it’s easier to fit a circle onto a page than a big rectangle
o It’s harder to keep it a consistent size on all the figures
o I like Joe’s suggestion of combining it with the legend, except with RVCT where the legend is huge any way.
logan_example2_perennial
logan_example1
logan_example1_perennial
logan_example2

@Albonicomt
Copy link
Contributor Author

@CHafen, These are awesome! I really like the context layers displayed in all four of the maps (Roads, lakes, borders, and cities), although, I do see what you mean about the increased time it takes to create them. And I especially like the bar graphs, with the cross hatching for area that display full and Perennial networks. I also think the background imagery in maps 1 and 4 looks better than just the white in maps 2 and 3. Thoughts?

Given that it takes a bit longer to make these types of maps, as @CHafen mentions above. @joewheaton and @wally-mac, what do you guys think is a good goal to shoot for when it comes to making these maps look good and keeping them simple enough, so we can produce a bunch of summary products for different areas?

The old maps use that base Reference layer, that already has some context, which quickens the process up a bit, but that base reference layer, depending on scale, displays some weird references and can look a bit faded. As I mentioned above, I really like @CHafen 's "context layer," and think it could be well worth the time for better and cleaner references.

@wally-mac
Copy link
Contributor

@CHafen, these look great! I think it is well worth the added time it takes to generate them.

@Albonicomt
Copy link
Contributor Author

@joewheaton @wally-mac and @CHafen Here are some attempts at combing the bar chart with the Legend for (1.RVD 2.Existing cap 3. RCA)

image
image
image

@wally-mac
Copy link
Contributor

wally-mac commented Oct 2, 2018 via email

@wally-mac
Copy link
Contributor

@kbartelt, I'm adding you to this ticket because per a conversation that @joewheaton and I had this morning he is going have you get "up-to-speed" on the lab's cartographic standard. This ticket addresses some current refinements to that standard. In the coming weeks, Chalese and Mic are going to continue to develop this standard and per Joe and I's conversation Joe would like you to be engaged in this process.

@joewheaton joewheaton added the duplicate This issue is marked as duplicate to another issue. label Oct 18, 2018
@joewheaton
Copy link
Contributor

This is similar to #188. I'm going to respond to a few specifics below...

@joewheaton
Copy link
Contributor

@joewheaton @wally-mac and @CHafen Here are some attempts at combing the bar chart with the Legend for (1.RVD 2.Existing cap 3. RCA)

I agree with @CHafen that:

suggestion of combining it with the legend, except with RVCT where the legend is huge any way.

However, what you did below really works well.

image
Delete label 'Overall Departure by Stream Length (%)' but use that font size and type for the vertical label 'Current Departure from Historic'

image
Delete label of 'Dam Count By Km (%)' and change font on vertical label as above

image
Delete the 'Condition Status by Km (%)' label.

@joewheaton
Copy link
Contributor

Here are some examples I came up with on Friday, but didn't get them up until now, so I have not yet incorporated @joewheaton comments.
But there is an example of showing the full network as a thin line. I think it looks pretty good with how it is in these figure, but I think with the other context labels that Joe is suggesting (especially names of major river/tribs) it will look messy. But I can add the labels to these figures and see how it looks.

I AGREE! These look fantastic for the examples where we decide to include the perrenial vs. intermittent and just vary the lineweight!

A few things to note:

• Labeling by hand is time intensive. Even without adding the other context labels Joe suggested it took about 3x longer to make these maps than the summary products we were producing. Though if we’re making several maps in the same area (ex. All RCAT and BRAT outputs) I only have to make the layout once per area

Good point. Understood and helpful for us to bare in mind in budgeting.

• I think the bar charts look nice and read well though they do have some down sides:
o They take 3-4x longer to make per figure than pie chars primarily because it’s easier to fit a circle onto a page than a big rectangle
o It’s harder to keep it a consistent size on all the figures

Understood, but they are far more useful than pie charts! Lets reserve them just for the summary products (not for the full atlas)

o I like Joe’s suggestion of combining it with the legend, except with RVCT where the legend is huge any way.
logan_example2_perennial

I really like having this choice of clean and simplified basemap (greyscale) with nothing more than hillshade on area of interest, and the aerial imagery for others. Very nice.

logan_example1
logan_example1_perennial
logan_example2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion among BRAT developers and power users. duplicate This issue is marked as duplicate to another issue.
Projects
None yet
Development

No branches or pull requests

4 participants