[aprssig] APRS symbols 1.3? FLOOD Gages and Radiation

[Lynn W. Deffenbaugh (Mr)]

I'm not a flood-guage person, but hopefully you'll take my (squawking) 
feedback.

Did you really mean capital-W?  They are NOT currently weather data and 
are not parsed as such.  They are Weather Stations.  The Underscore and 
lower-case w are all that are currently parsed for weather that I'm 
aware of.

So, with what I read below, we go from TWO underscore and lower-case w 
to FOUR underscore, lower-case w, upper-case W, and upper-case H 
possibly base symbols, ALL of which MIGHT contain weather-formatted 
sensor data?

Is that really your intent?  Why not just keep it underscore and 
lower-case w with overlays on the w to pick up the new "weather" sources?

Why parse Hazards for weather data?  They, as you mentioned earlier, 
should be objects, possibly area objects, showing the hazard and the 
extent of the hazard, not measurements all the time.

And I don't know who, if anyone, uses Weather Stations (capital-W), but 
to my knowledge it has never had measurements being parsed from it before.

Lynn (D) - KJ4ERJ - Author of APRISCE for Windows Mobile and Win32

On 3/24/2011 11:06 AM, Bob Bruninga wrote:
> OK, How this!?
>
> Flood Gauge people please give us feedback!
>
> This proposal is a continuation of the great symbol set expansion proposed
> under aprs 1.2 back in 2007.  That is, that Overlay characters could be
> added to ANY symbol, thus increasing the combined combination of symbol
> indicators by hundereds.  Both Kenwood and Yaesu now already support
> universal overlays in their radios.
>
> This discussion of Radiation Hazards and Radiation Sensors has caused a
> thorough re-look at where we stand.  We simply need to expand the overlays
> for WX stations.  Currently /W and \W should be parsed for Weather.  So
> shouldn't also #W with any overlay?  In that case, I propose the following
> overlays for the WX symbol so they are backwards compatible to existing
> symbol sets:
>
> 1) RW is a weather station highlighting its Radiation Sensor (#W)
> 2) FW is a weather station highlighting its Flood Gauge (was /w or \w)
>
> These stations can automatically change their symbol depending on what is
> going on.  If either the Radiation sensor or Flood gage is showing BENIGN
> readings, then it can simply show the WX symbol (/W) but when elevated
> readings of either sensor begin to rise, the station can change its symbol.
> When a SERIOUS threshold is exceeded, these same stations can then change
> their symbol to either of the following HAZARD symbols
>
> 3) RH is a Radiation Hazard OBJECT to HIGHLIGHT a radiation Hazard
> 4) FH is a FLOODING HAZARD to highlight a flooding hazard
> 5) WH is a WIND HAZARD
>
> The result to client code is that only #W (weather) and #H (hazards) need to
> be scanned for all Weather and other SENSOR data, not an ever incremental
> change to code for each new symbol added.  Here is the impact on CODE?:
> That is, now, only /W, \W and #W symbols need to be parsed for weather data
> (which can include FLOOD data and Radiation data).. plus since 2007, /w and
> \w for floods.
>
> This seems like the most simplest and consistent approach.  BUT The problem
> is that in 2007 we suggested /w for flood gages and \w for FLOODING events.
> Has this made it into any NON-CHANGEABLE hardware or software?  Probably so.
> Therefore, we still need to allow for legacy checking of /w and \w symbols
> for weather and flood info.  But can we phase this out in the long term?
>
> Flood gauge people, please comment.
>
> Bob, wb4apr
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>