:otherwise syntax

[kbagstad]

@fvilla @lambdatronic

when running model -o foo.nc core.models.carbon-colorado/soil-storage core.contexts.colorado/colorado, two weird things to report. First, I've used an ":otherwise" statement at the end of defmodel soil-type to catch rock and water in that layer (these are represented by just a space in the value field). Unfortunately neither the :otherwise statement nor replacing it with " " seems to catch the rock and water cases and they get submitted as nodata, which is of course wrong. Also strangely, the "landorwater" values reported in the same modeling statement all come out as 0's in my netCDF. This is weird because I use identical syntax (though different land/water values) for the sediment-colorado model, yet the sediment one gives a proper looking output with 1's for the land and nodata otherwise (try model -o foo.nc core.models.sediment-colorado/land-selector core.contexts.colorado/colorado). Strangely the non-land values are masked out properly in both models, it's just inconsistent behavior, which always worries me.

If either of you have the time to give this a look it would be helpful.

[lambdatronic]

Well, the syntax in the soil-type model looks right to me, Ken. I'm wondering if Thinklab's categorization statement is just setting the " " field to nodata because it only contains whitespace. Ferd will have to make the call on this one.

[fvilla]

sorry guys, I've been desperate after getting back from London and oversaw this one. Using whitespace for a category is entirely not OK - point is, this stuff is communicated through XML and if we keep whitespace anywhere it's going to maybe solve this problem but create millions others. It's entirely evil to structure a shapefile that way, not to mention unreliable. I am pretty sure that leading/trailing whitespace is removed from category in my code, so there's a chance that an empty string ("") will match, but the real solution is to get a proper shapefile - i.e. substitute all those silly attribute values with "RockAndWater", put it in GS and match that. I'll try to look at this specifically when I'm out of my 10 meetings.

[kbagstad]

OK, will take another shot at fixing yet more bad GIS data. Re: the funny masking behavior (the second part of the issue as first written), try model -o cland.nc core.models.carbon-colorado/land-selector core.contexts.colorado/psi-view-30-mile and model -o sedland.nc core.models.sediment-colorado/land-selector core.contexts.colorado/psi-view-30-mile

Strange that these should be different, especially since carbon (the problematic one) should return more null values than the sediment one.