Intent to Implement: Aviation Unit System
mwall
from jamesshannon on 11sep2017:
Hi,
I'm just discovering weewx and want to say hi. I'm working on a project to set up a weather monitoring solution for airports. As you can imagine, weewx provides a ton of functionality. Since I was planning on writing this in Python, it was a no-brainer to leverage weewx.
That means that you can expect lots of questions and comments and sometimes commits from me. :) However, I realize that your focus isn't aviation so for things that are more aviation-weather-monitoring vs home-weather-monitoring, I figure I'll run my proposal by you first to get your input.
In this case I'm interested in adding a new unit system for aviation. It'll be similar to the US, but with a few changes -- windspeed in knots, for example.
I could, of course, do the conversions myself after StdConvert runs (or replace StdConvert), but I feel like it makes sense to build this in. Thoughts?
mwall
I could, of course, do the conversions myself after StdConvert runs (or replace StdConvert), but I feel like it makes sense to build this in. Thoughts?
is there any reason that you cannot do everything in the skin definition for a report?
the newskin branch should make this even easier when it merges to master. specifically, you can specify 'default_options', including units, that will then be applied to every report.
so your aeronautic default might look like this:
[StdReport]
...
[[default_options]]
[[[Units]]]
[[[[Groups]]]]
group_altitude = foot
group_speed = knot
group_speed2 = knot
group_pressure = inHg
group_rain = inch
group_rainrate = inch_per_hour
group_temperature = degree_F
group_degree_day = degree_F_day
then every report would use those units, with no changes required to any report, and no need to duplicate the units stanza in weewx.conf. (of course, you can still override those defaults per-report or per-report-instance)
this is just a suggestion so you don't get bogged down in units when there are so many other aviation-specific extensions that could be done. for example, plotting wind direction and history on openstreetmap images of runways, reports that combine local real-time conditions with forecasts, aviation-specific calculations in a service analogous to StdWXCalculate, real-time conditions from airborne instruments and sensors, ...
or even more basically, defining an aviation-oriented database schema that tracks cloud height, visibility, and other metrics that the default weewx schema does not include.
m
mwall
from jamesshannon:
So I'm still digging through weewx to understand the architecture. It's not too hard, but it's not trivial, either. It'll take me a while to determine true best practices.
I "need" up-to-the-minute weather (aka, one-minute weather). I also want it programmatically (in a data structure) and don't want to futz with parsing it from a report, or even querying the DB. In fact, I was initially planning on using just the drivers, but have since moved up to the engine. I'm hesitant to use the archive or report facilities for this, but I suspect part of that is just because that's another layer I'd have to understand. I also feel like it's better to do the conversion once, close to the data source, rather than convert multiple times.
I'm focused on the raw data for the medium-term with the"report" being a TTS voice, which I suspect is far outside the scope of weewx, and I'm fine with that.
FWIW, so far, it seems that StdWxCalculate handles all the reasonable aviation calculations -- namely cloud height (though I'm not sure if this gets archived). The only thing it's lacking is nautical-mile units for distance.
Other than drivers for equipment like the Campbell Scientific LIDAR ceilometer or transmissometers*, I don't see much that weewx could do beyond the current (iffy) cloud height calculation.
- AFAICT, weewx just isn't set up to talk to multiple independent
sensors in this way. (I have some ideas to measure visibility, and was
planning on doing this outside of weewx, though other than the
single-driver architecture, I don't see a reason why this couldn't be
part of weewx.)
mwall
there are a few ways to collect data from multiple instruments and/or types of instruments:
-
driver plus service(s). the driver collects data from the 'primary' instrument, with one or more services running to collect data from additional instruments. for example, use the vantage driver to collect data from a davis weather station, with the owfs service to collect data from one-wire sensors. pro: single instance of weewx, single report generation. con: becomes unwieldy if there are many different types of instruments.
-
one weewx instance per instrument. run a weewx instance for each instrument. run wee_reports as a cron job with a configuration that produces a report with data combined from all the instruments. pro: possibly more robust if a single instrument fails. con: gotta manage multiple processes.
imho, when you get into the realm of real-time data, then you really should use MQTT. configure each weewx instance to send data to an MQTT broker. then configure an influxdb server as a consumer to the MQTT feeds. that way you get weewx saving data locally, so you can recover gaps in data from network outages, for example. and you get a single, real-time (or near-real-time, depending on your sensors) source to get the current data (MQTT broker) and fast database for central access to all historical sensor data (influx database).
if you don't need local reports, then don't run the weewx reports.
if you don't need centralized historical data, then don't run influx.
