PaleoCAR water-year precip styling needs improvement

[jterstriep]

PaleoCAR, Water Year Precip map view is virtually useless because everywhere anyone ever lived is always green. The scale goes from 0 to 6 meters (6000mm). Most of the sw most of the time is on the order of 30cm. An upper bound of interest would probably be 1m. However, I assume the scale is, reasonably, set from the min to the max for the whole dataset. I can see values up in the 3m range, so maybe 6m is possible, but it could also be bad data. If there is some easy fix for this that would be great (e.g. to get the min and max from the selected area, for now; or to set a metadata value for the display min and max). Alternately we need to get the range limit option working as soon as we can.

[kintigh]

From Note in Won'd do column:

The issue here is what will the map default to for the range of values in the legend that dictate the colors. Implementing the overlay range will allow people to change that. Right nowit appears that we o have a mixture of something set in the metadata and the data range. Paleocar GDD 0-6000 (as it is at present) Paleocar Precip 0-1000 Paleocar Niche 0-1 LBDA -6 - +6 (as it is at present) PRISM min/max temp 0-100 PRISM Precip 0-2000 Elevation 0-3000

[jterstriep]

PaleoCAR water-year has been updated with a new color ramp for the range 0-1000.

[tmcphillips]

We can leave this issue closed.

However, I would like to add that in general we cannot assume that the min and max values are the most meaningful and appropriate ends of the default color ramp scale for a data set. A histogram of values in a data set may reveal very extensive--yet skinny--tails on the distribution, such that using the min and max of the distribution will completely wash out any contrast within the bulk of pixel values of interest to the user. The LBDA data set is an example of this.

[bocinsky]

I concur with Tim on this. It seems reasonable to set the bounds for the default color ramp around something like the middle 95% of the data. Of course, the best option would be to enable people to set the bounds of the color ramp themselves. [Earth Engine](https://explorer.earthengine.google.com/#workspace https://explorer.earthengine.google.com/#workspace) does a good job of this.

On Jun 26, 2018, at 3:25 PM, Timothy McPhillips notifications@github.com wrote:

We can leave this issue closed.

However, I would like to add that in general we cannot assume that the min and max values are the most meaningful and appropriate ends of the default color ramp scale for a data set. A histogram of values in a data set may reveal very extensive--yet skinny--tails on the distribution, such that using the min and max of the distribution will completely wash out any contrast within the bulk of pixel values of interest to the user. The LBDA data set is an example of this.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openskope/Datasets/issues/10#issuecomment-400467677, or mute the thread https://github.com/notifications/unsubscribe-auth/AH8pMxibSZPYAfYaqxOT6oih4HXe16Xxks5uAqbRgaJpZM4UFYII.

[kintigh]

Yes, it is actually VERY important that users be able to set this. For example, if one is interested in precipitation needs for agriculture in the SW the color ramp for the whole range of US precip values in PRISM or SW values in PaleoCAR or PRISM is essentially useless because even paleocar includes some high elevation mountains that get high precip. As a result, one cannot see the relevant variation between perhaps 150 and 600 mm (or an even narrower band) which is where all the practical action might be in a given area. I think there is an issue to make this user definable, but if there isn’t there should be. A 90 or 95% window will not solve this. Keith

---

Keith W. Kintigh, Professor kintigh@asu.edumailto:kintigh@asu.edu ASU Directory Pagehttps://webapp4.asu.edu/directory/person/56433 ASU School of Human Evolution & Social Changehttp://shesc.asu.edu/ ASU Center for Archaeology & Societyhttps://shesc.asu.edu/centers/archaeology-and-society, Co-director Arizona State Universityhttp://asu.edu/, Box 872402, Tempe, AZ 85287-2402

Coalition for Archaeological Synthesis<http;/archsynth.org>, Interim Co-Chair Journal of Computer Applications in Archaeologyhttp://journal.caa-international.org/, Editorial Board

From: R. Kyle Bocinsky notifications@github.com Sent: Tuesday, June 26, 2018 3:50 PM To: openskope/Datasets Datasets@noreply.github.com Cc: Keith Kintigh kintigh@asu.edu; Comment comment@noreply.github.com Subject: Re: [openskope/Datasets] PaleoCAR water-year precip styling needs improvement (#10)

I concur with Tim on this. It seems reasonable to set the bounds for the default color ramp around something like the middle 95% of the data. Of course, the best option would be to enable people to set the bounds of the color ramp themselves. [Earth Engine](https://explorer.earthengine.google.com/#workspace https://explorer.earthengine.google.com/#workspace) does a good job of this.

On Jun 26, 2018, at 3:25 PM, Timothy McPhillips notifications@github.com<mailto:notifications@github.com> wrote:

We can leave this issue closed.

However, I would like to add that in general we cannot assume that the min and max values are the most meaningful and appropriate ends of the default color ramp scale for a data set. A histogram of values in a data set may reveal very extensive--yet skinny--tails on the distribution, such that using the min and max of the distribution will completely wash out any contrast within the bulk of pixel values of interest to the user. The LBDA data set is an example of this.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openskope/Datasets/issues/10#issuecomment-400467677, or mute the thread https://github.com/notifications/unsubscribe-auth/AH8pMxibSZPYAfYaqxOT6oih4HXe16Xxks5uAqbRgaJpZM4UFYII.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openskope_Datasets_issues_10-23issuecomment-2D400474230&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=ur9s2KurOEwuMPidvsiKCoRQF9hp3xq6Pgyn4VShajU&m=7uqSSby_bC49cu18jzLZJkMr_KJozxCMfYw6r7yEYvQ&s=kdJdFYJclttSa_4maw0BX5Ymrn-crVQKL1ziKOByyEc&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ALAoJaKoV0HActMQExJe34BOw4ek9PWwks5uAqx4gaJpZM4UFYII&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=ur9s2KurOEwuMPidvsiKCoRQF9hp3xq6Pgyn4VShajU&m=7uqSSby_bC49cu18jzLZJkMr_KJozxCMfYw6r7yEYvQ&s=cWDAmqvRBGClCimfR0bHU6AJPX8JTKevA-9ujsCTNAQ&e=.

[tmcphillips]

Yes, a single color ramp does not solve the problem of no contrast when zoomed in to a particular region with less variation than the data set as a whole. I think we need a good default color ramp for the data set as a whole, but I think the users should be able to (1) request a new color ramp be automatically computed based on the distribution of values currently in view; (2) choose to manually set the min and max values for the color ramp; and (3) ideally do (2) in light of (or on) a displayed histogram of the values in view rather than just typing in numbers and discovering the best range by trial and error (and possibly missing something important).