Closed mmcfarland closed 8 years ago
Did they say what in particular they were having trouble with?
It should also be noted that the values for LIR, HIR, Commercial, Forest, and Turf Grass will be different between the old flash version and the new Micro Site, because of reasons specified in #185:
Incongruous Land Code Interpretation
The Flash app interpreted the
land
values as follows:var landCodes = { 21: LandCovers.LOW_INTENSITY_RESIDENTIAL, 22: LandCovers.HIGH_INTENSITY_RESIDENTIAL, 23: LandCovers.COMMERCIAL_INDUSTRIAL, 43: LandCovers.FOREST, 85: LandCovers.TURF_GRASS, 81: LandCovers.XYZ, 71: LandCovers.GRASSLAND, 82: LandCovers.ROW_CROPS, 91: LandCovers.WETLANDS }
But the official definition of these codes is different: http://www.mrlc.gov/nlcd11_leg.php
This official description is the one used by TR-55: https://github.com/WikiWatershed/tr-55/blob/develop/tr55/tables.py#L387-L414, and also by the new mini-app:
landMap: { '21': 'turfGrass', '22': 'lir', '23': 'hir', '24': 'commercial', '41': 'forest', '71': 'grassland', '81': 'pasture', '82': 'rowCrops', // TODO The following are missing NLCD identifiers. // Replace X? with actual numbers when that data is available. 'X0': 'chaparral', 'X1': 'tallGrass', 'X2': 'shortGrass', 'X3': 'desert' },
The current configuration in the micro app, as of #209, is:
landMap: {
'21': ['turfGrass', 'tallGrass'],
'22': ['lir'],
'23': ['hir'],
'24': ['commercial'],
'31': ['desert'],
'41': ['forest'],
'52': ['chaparral'],
'71': ['grassland'],
'81': ['pasture', 'shortGrass'],
'82': ['rowCrops']
},
Here's a table of mappings in both:
NLCD Code | Old Flash App | New Micro Site |
---|---|---|
21 | LIR | Turf Grass, Tall Grass Prairie |
22 | HIR | LIR |
23 | Commercial | HIR |
24 | Commercial | |
31 | Desert | |
41 | Forest | |
43 | Forest | |
52 | Chaparral | |
71 | Grassland | Grassland |
81 | XYZ | Pasture, Short Grass Prairie |
82 | Row Crops | Row Crops |
85 | Turf Grass | |
91 | Wetlands |
Does this answer their concerns or do they have more questions?
Regarding rounding, the old flash app displayed values rounded to one decimal place. Should we up that to two?
Actually, we're not rounding the values on the display side at all. Those are straight from the CSV file. If we need more detailed data, we're going to have to update that CSV.
@rajadain thank you for the table above, I think that may be the issue.
Specific comments I've received, verbatim:
Validate ET numbers. some seem off, for example forest is less than cropland and Chaparral for average rainfall. I saw this also.
HIR and Commercial numbers for infiltration are the same. It seems that Commercial runoff should be higher.
Some of the amounts do not add up Sandy Loam 8 inches See hand written list provided by Bill. only checked average rainfall setting
I'm looking into the "hand written list" by Bill.
Some of the amounts do not add up
Yes, the rule for evapotranspiration is such that the numbers may sum to more than the total precipitation. I remember being slightly surprised by this when I cam across instructions in some of the old communications to handle it this way. I think the idea is that this quantity is does not strictly depend on precipitation.
Also if the difference is small, it may be due to our course rounding.
Validate ET numbers. some seem off, for example forest is less than cropland and Chaparral for average rainfall. I saw this also.
HIR and Commercial numbers for infiltration are the same. It seems that Commercial runoff should be higher.
Some of the amounts do not add up Sandy Loam 8 inches See hand written list provided by Bill. only checked average rainfall setting
I guess we can double check the curve numbers and whether the right NLCD codes are being used for each type.
My understanding of ET is that it is more or less fixed as a function of the capacity for photosynthesis and does not change based on the precipitation. @aufdenkampe explained this well in the Millersville demo, I'll try to find the explanation he used. @chitchens is it recorded in notes anywhere, or have you seen a link to the video that was made?
You're correct, but this is the only note I have on it:
Q: Is evapotranspiration fixed? A: Yes, the calculation assumes an average sunny day.
I think it's technically a variable based on the amount of sunlight, but for the purpose of this model we're just applying a fixed value.
I haven't seen a link to the video, but I'll try to track it down.
It is also very possible that some of the NLCD codes added here are incorrect: https://github.com/WikiWatershed/tr-55/commit/c296fe6225426c09df40094a137c09507ef4a878 .
I just used the microsite for the first time and was a little confused by the output.
Adjusting the precipitation for the commercial land use type (with any soil type) shows only runoff until 2 inches, at which point the infiltration and runoff are split evenly. As you progress further, the runoff steadily increases, while the infiltration steadily decreases. The changes in infiltration did not make sense to me. It may not be linear, but for there to be none, then half, then have it steadily decrease seems odd at first.
@jamesmcclain explained that we are using one model for < 2"
inches of rainfall and one model >= 2"
of rainfall, and the transition of the results between the two is not smooth.
Although the first version of the app does behave in the same way, this may or may not be a source of confusion for some users.
Just a minor correction, we are using one model for <= 2" and the other for > 2".
I think that the thing that is most confusing is the relative proportions of the quantities. For example: if you are looking at High-Intensity Residential with Clay Loam, you will notice that when you transition from 5.1 cm (2 inches) to the next increment 8.1 cm, the proportion of infiltration in the bar graph to the right drops precipitously. Runoff and infiltration have both increased, but runoff has increased at a much greater rate.
But just to add on: because infiltration is essentially what is left after you have computed runoff and et, it certainly is possible for infiltration to actually go down in absolute terms as you pass from <= 2" of rain to > 2".
I agree the values can look strange, but Stroud specifically requested the Pitt Small Storm model at values under 2".
We're now using actual NLCD classes which should avoid mapping value issues, I'd like to close this and submit new issues when and if other discrepancies are discovered.
There were numerous comments from teachers indicating that the numbers provided by the microsite were incorrect or inconsistent. This is partly do to misconceptions (ET is fixed a specific rate) and rounding - but there was some concern that the values were incorrect.
I'll update the issue with specific comments for specific combinations if I can dig them up.