wee_import should process illuminance and compass point directions

[gjr80]

Some stations measure illuminance in lux and some software approximates solar radiation (W/m²) from illuminance. For example, the WMR300 provides illuminance data and the WeeWX WMR300 driver calculates an approximate solar radiation value from this data. It is not unreasonable for wee_import to process illuminance data and approximate the WeeWX radiation field from this data. As of v3.7.0 the only illuminance processing occurs in drivers of stations providing illuminance data, if wee_import is to process illuminance data then it may be appropriate to adopt a standardised conversion through StdWXCalculate.

As an aside, if/when WeeWX records illuminance data it will be a simple extension of wee_import to import illuminance data directly.

Some stations discriminate wind direction using a limited number of directions (typically compass points - 16 points is common). As WeeWX stores direction in degrees only, drivers for such stations convert such directions to degrees; for example, the Davis Vantage stations provide a '16 point' wind direction in archive records and the vantage driver converts this to degrees. Given this situation it is not unreasonable for wee_import to accept compass points as directions that would be converted to degrees before being saved to archive.

This enhancement will only be applied to imports from CSV format files as WU history data and WD, Cumulus and WeatherCat data files are fixed in format and both provide wind direction in degrees (WU actually provides both compass point directions and degrees).

[gjr80]

wee_import CSV imports now support the use of cardinal, intercardinal and secondary intercardinal directions in source data for fields using degree_compass units. Commit 3b8932d86462bf850207a53f1837e877f60a99dc refers.

[gjr80]

Given all the water that has gone under the bridge since this issue was first raised (wview_extended schema introduced, issues over correct terminology of illuminance/luminosity fields and the introduction of the --calc-missing command line option for wee_database) I am wondering if we should have wee_import directly calculating derived obs such as radiation or if we should be dealing with it under --calc-missing?

At the moment --calc-missing uses an instance of StdWXCalculate to calculate missing derived obs. WeeWX does not use StdWXCalculate to calculate radiation (if it is missing), rather the accepted approach is for the user to add an entry under [StdCalibrate] [[Corrections]]. Such an entry would be ignored when --calc-missing is run. A number of options come to mind:

1. Have --calc-missing pick up and process the [StdCalibrate] [[Corrections]] entries. This would work for radiation as it's calculation is based upon other fields but it could fail on other fields that are scaled/correct versions of themselves (eg, outTemp = outTemp + 2).
2. Add radiation to StdWXCalculate with a 'radiation XType', given the divided opinion over this 'calculation' perhaps set to hardware by default so that the user must deliberately invoke the XType.