You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There appear to be some areas in the code base that still have a hard-coded assumption of 3 categories for non-road models. For example, I believe that when raw prediction values are saved during mapping, they are stored in a 3-band tif, without regard for the model typology. All parts of the code base related to training, mapping, and scoring models need to be checked for this type of hard-coding, and instead use parameters or some inference (eg model output nodes) to account for the possibility of non-trinary classification.
The text was updated successfully, but these errors were encountered:
Want to bring special attention to correcting model scoring, whether at creation or application. This is heavily hard-coded. Want to make this robust enough to handle up to 7-category models. Practically speaking, it will be 3-category, 6-category, or 2-category (roads) models. Will make something ugly but robust--one size fits all--and close the book there. An early priority for next development phase will be a fresh recordkeeping paradigm.
There appear to be some areas in the code base that still have a hard-coded assumption of 3 categories for non-road models. For example, I believe that when raw prediction values are saved during mapping, they are stored in a 3-band tif, without regard for the model typology. All parts of the code base related to training, mapping, and scoring models need to be checked for this type of hard-coding, and instead use parameters or some inference (eg model output nodes) to account for the possibility of non-trinary classification.
The text was updated successfully, but these errors were encountered: