The main problem being experienced in the development of this system is that there is no fixed format for Warnings from BoM.
Each type of warning has a different format - and within the warning type the format and syntax changes between states, and even between forecasters in the same state!

This is the primary reason for the first disclaimer - whilst every effort has been made to cover as many syntax variations as possible, it is inevitible that there will still be some instances where warnings are not transmitted, or transmitted to an incorrect area due to an unknown syntax or format.

This is the format of a warning taken from the NWS RSS feed. Everything is there that is needed for construction of the APRS messages (shown in red):

Compare this to what we have to work with from our local BoM. Only a handful of details can be extracted (in red). Others can be derived, but most of the message must be a 'best-guess' based on the available data.

Ideally BoM would need to provide a formatted list of affected areas (In fixed format abbreviations or area numbering) and an expiry time, and not combine warning types (Gale and Strong Wind in this example) As it stands today all regions mentioned in the warning will get the highest severity warning, even if it is not valid for that area.

BoM use Local Government Area boundaries for Severe Thunderstorm Warnings in the major capital cities. The LGA shapefiles used by this project (freely available from the Australian Bureau of Statitics) reference each LGA by a numeric 5 digit code. Even the standard Forecast areas could be referenced by a numeric code, as done by the NWS. If BoM were to include a simple list of affected LGA/Forecast area numbers in the warning headers, this issue would largely be resolved.

In order to maintain compatibility with the existing NWS client applications, the naming convention of the Shapefile Maps used by this project are the same as the NWS issued maps. This means that you can use EITHER the Australian version OR the NWS version - not both.

Also in order to maintain compatibility with the existing NWS client applications, The STATE prefixes used in the APRS messages are truncated to 2 characters to match the US standards. The side effect of this is that the state as shown in the client windows is a 2 character code instead of the expected 3 characters.

To overcome these, custom clients could be developed for the various APRS applications - however this is outside the scope of the project at this stage.

Warning areas are huge. Again it comes down to the clarity of the warnings - a warning issued for "Southern parts of the Lower Western" covers a huge area, with no definition of where "Southern parts" actually are. At this stage we can only highlight the entire area, which may result in 'invalid' warning status for some areas.

Relates to item 1 - if BoM were to break warning areas into LGA's and include effected LGA numbers in the warning a more accurate warning area display could be triggered.

There is no "Finger" capability built into WXSVR-AU at this stage. Attempting to use the FINGER functions on existing NWS clients will result in an error being returned from WXSVR (USA version).

Finger support is planned for the future, but to use it we'll need to have localised NWS clients, or a configurable option to select the server to use.