fertilizer_composition_data has no dedicated column for urea-N, so urea content gets shoehorned into one of the existing columns inconsistently across rows.
For example, three rows that all describe urea-N encode it three different ways:
Three rows, chemically identical urea-N, three different encodings.
The fix is to add a fraction_urea_n column, re-encode the affected rows (urea / 46_00_00 / uan_32) so each N form lives in its own column, and update convert_swat_fert_table_to_pkg_df() to populate it from the SWAT source.
Downstream consumers that currently sum nh3_n + no3_n + organic_n to get total N will need to also include urea_n after the migration.
Surfaced during #3962; that PR's uan_32 row will get a one-line update once this column lands.
fertilizer_composition_datahas no dedicated column for urea-N, so urea content gets shoehorned into one of the existing columns inconsistently across rows.For example, three rows that all describe urea-N encode it three different ways:
urea: 0.46 N stored asfraction_nh3_n46_00_00(also urea): 0.46 N stored asfraction_no3_nuan_32(added in Add UAN-32 and CAN-17 to fertilizer_composition_data #3962): 0.165 urea-N stored asfraction_organic_nThree rows, chemically identical urea-N, three different encodings.
The fix is to add a
fraction_urea_ncolumn, re-encode the affected rows (urea / 46_00_00 / uan_32) so each N form lives in its own column, and updateconvert_swat_fert_table_to_pkg_df()to populate it from the SWAT source.Downstream consumers that currently sum
nh3_n + no3_n + organic_nto get total N will need to also includeurea_nafter the migration.Surfaced during #3962; that PR's
uan_32row will get a one-line update once this column lands.