[OZAPRS] Message Traffic and WX Alerts in Xastir
Ray Wells
vk2tv at exemail.com.au
Thu Nov 27 13:29:51 EST 2008
Geoff, David and other equally confused onlookers,
Geoff wrote:
> I don't believe so....
>
> Here's a sample of zone messages from the US WXSVR....
>
> ABQWSW>APRS::NWS_ADVIS:262230z,WINTER_WEATHER,NMZ2-4 {QC5AB
> AJKNPW>APRS::NWS_ADVIS:270800z,WIND,AKZ26 {QKiBB
> BMXRFW>APRS::NWS_WARN :262230z,RED_FLAG_WARN,ALZ45-46-48>50 {QLKAB
> CARFFA>APRS::NWS_WATCH:262300z,FLOOD,MEZ10-11-15>17-29>32 {QFsAA
>
> The messages transmitted by the server are all in the format of
> <STATE><Z/C><Zonelist>
>
> A sample of our messages from WXSVR-AU shows the identical format
>
> SYDSWW>APRS::NWS_ADVIS:270000z,WIND,NSZ531 {QHHAA
> SEHSWW>APRS::NWS_ADVIS:270000z,WIND,TAZ504>505 {QHkAA
>
> I think Xastir is re-formatting the zone payload for display purposes -
> separate the state from the Z/C and numerical portion. (It will be doing
> this for the warnings that work as well)
>
From my z_aus20no08.dbawk file which is essentially a copy of the
example dbawk.
# BEGIN is called once per dbf file which contains multiple records.
BEGIN {
# dbfinfo is the "signature" of the dbf file listing the column names in
order.
# dbfinfo should match the dbf file that we say this dbfawk file goes with.
dbfinfo="STATE:ZONE:CWA:NAME:STATE_ZONE:TIME_ZONE:FE_AREA:LON:LAT:SHORTNAME";
# dbffields is which of the above fields we actually want to look at.
# Note that the order we list these is important since we are appending the
# word County or Parish depending on what state the county is in.
dbffields="STATE_ZONE:NAME";
}
# BEGIN_RECORD is called once per dbf record which contains multiple fields.
# Use this rule to re-initialize variables between records.
BEGIN_RECORD {key="BOGUS"; lanes=2; fill_color=7; color=8; name="";
filled=0; fill_style=0; pattern=0; display_level=65536; label_level=512;
label_color=20; font_size=2; symbol=""}
/^STATE_ZONE=(..)(.*)$/ {key="$1_Z$2"; next}
/^NAME=(.*)$/ {name="$1"; next}
Now, looking at z_aus20no08.dbf in qgis we see this, as an example,
STATE NS, ZONE 015 STATE_ZONE NS015
Note the latter is not NSZ015
Does the line, above, /^STATE_ZONE=(..)(.*)$1/ (key="$1_Z$2";
next}attempt to create NS_Z015? Is the dbawk file looking for, or trying
to create, wrong parameters?
Just another of many thoughts.
> I'm trying to research that mystery field in the alert log a bit more, but I
> have a funny feeling that the first character relates to the COLOUR of the
> alert area - on the working example you gave before it was YN and a YELLOW
> area was drawn... On the two 'broken' examples this field was ?N and ?Y.
> I'm thinking perhaps there is no colour defined for ADVIS messages in your
> setup?
>
> Xastir uses the following colours:
> ADVIS = Cyan (Yellow in UIView)
> WATCH = Yellow (Orange in UIView)
> WARN = Red (Red in UIView)
> CANCL = Orange (Clears shape in UIView)
> TEST = Blue (Not supported in UIView)
> OTHER = Green (Purple in UIView)
>
> Still looking but it may be a clue ??
>
> Geoff
>
>
>
Ray vk2tv
> -----Original Message-----
> From: ozaprs-bounces at aprs.net.au [mailto:ozaprs-bounces at aprs.net.au] On
> Behalf Of David
> Sent: Thursday, 27 November 2008 8:14 AM
> To: Australian APRS Users
> Subject: Re: [OZAPRS] Message Traffic and WX Alerts in Xastir
>
> Hi Geoff and Ray....heres my latest piece of info FYI
>
> wx_alert log
> # 1227732315 Thu Nov 27 06:45:15 EST 2008
> NECSWW>APRS::NWS_ADVIS :270000Z,WIND,TAZ506 {QHkAA
>
> this is the same as you sent me in the e-mail
>
> WX ALERT LIST
> NECSWW QHkAA NWS_ADVIS 26 at 1746Z ------------> 27 at 0000Z ?Y
> TA_Z506 WIND
>
> i presume this is how Xastir is dealing with the data that is coming in
> as per the wx_alert.log
>
> Geoff you mentioned that UI-View would use TAZ506 and the expiry time
> and date....
> looks like Xastir may be using TA_Z506 would the "_" make any difference ??
>
> David VK4BDJ
>
> Ray Wells wrote:
>
>> Geoff,
>>
>> Thanks for the additional info. I spent hours yesterday disseminating
>> what I've got and gathering information on how it fits together. I was
>> also looking for an example of some US aprs weather bulletins - more
>> searching when I get home later today.
>>
>> I also wondered about those extra characters but since I'm wandering
>> around in the dark I didn't pay too much heed without knowing their
>> relevance.
>>
>>
>>
>> Geoff wrote:
>>
>>> I can't answer the Xastir specific queries, however how the
>>> shapefiles are
>>> triggered is as follows:
>>>
>>> Each shape within each shapefile is assigned a field that is used to
>>> 'trigger' the shape (Each shapefile has a unique .dbf format - we just
>>> copied what the Yanks use)
>>>
>>> In the z_ausXXXX file for example, the .dbf contains STATE, ZONE and
>>> STATE_ZONE. These are defined within the .dbf as for example NS,
>>> 025, and
>>> NS025 respectively.
>>>
>>> The APRS message that triggers this zone contains the state and zone(s)
>>> required to be highlighted (Leading 0 is insignificant)
>>>
>>> The APRS message itself looks like: UPWSTS>APRS::NWS-WARN
>>> :260830z,TSTORM,NSZ25 {Q5QAB
>>>
>>>
>> In wading through the examples posted by David yesterday, and my own
>> log entries, I came to the conclusion that the particular dbf file to
>> use is triggered by the zone information.
>>
>> A bulletin containing NS_Z021 looks in z-aus...dbf, one using NS_Z541
>> uses mz_aus...dbf, and one using NS-C021 uses c_aus...dbf
>>
>> Logically, if a particular dbf is used the matching shp and dbfawk
>> files are used.
>>
>> If my thinking is flawed please tell me. I can't fit it all together
>> if I'm using bits from another puzzle :-)
>>
>>
>>
>>> Now I'm not sure how Xastir handles this, but in UI-View, all it
>>> cares about
>>> is the NSZ25 part and the expiry time. TSTORM is a "plaintext"
>>> identifier
>>> that only shows up within the NWS plugin, and the shape is automatically
>>> hidden when the expiry time passes.
>>>
>>> Objects on the map are just that - objects, triggered by an object
>>> beacon,
>>> like this one:
>>> UPWSTS>APRS:;UPW_STS *260830z3023.94S\14310.20ETSevere Tstorm {Q5QAA
>>>
>>> The symbol used to represent the Thunderstorm is Symbol-set \
>>> (Alternate)
>>> symbol T. We're using the same symbols as the US NWS messages, so they
>>> should be available.
>>>
>>>
>> Icons appear to be ok here.
>>
>> Ray vk2tv
>>
>>> Regards,
>>> Geoff VK2XJG
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ozaprs-bounces at aprs.net.au [mailto:ozaprs-bounces at aprs.net.au] On
>>> Behalf Of David
>>> Sent: Wednesday, 26 November 2008 3:30 PM
>>> To: Australian APRS Users
>>> Subject: Re: [OZAPRS] Message Traffic and WX Alerts in Xastir
>>>
>>> Hi Andrew......ive been getting areas with Yellow and Flood for some
>>> time now....also was getting Blue Alert at one stage.....
>>> at the moment we have large areas with STS Severe Thunderstorm Storm
>>> warnings....
>>> i note that in the /usr/local/share/symbols dir there is no .xbm for
>>> Thunderstorms...would this cause them not to be shown up as colored
>>> areas as they are in UI-View (Red)...if this is so how would one go
>>> about making a .xbm for Thunderstorms.....have tried to change the
>>> file name of the Tonado one to see if it worked ...nix...
>>> how does the .shp file pick up which warning and what it is from
>>>
>>>
>>>
>>> 73 David VK4BDJ
>>>
>>>
>>>
>>> Andrew Errington wrote:
>>>
>>>
>>>> I did a quick experiment.
>>>>
>>>> I have made my own .dbfawk files for the map data from here:
>>>>
>>>> http://mapcenter2.cgpsmapper.com/mapsetview.php?id=185
>>>>
>>>> (You can get maps of Oz too, but for any of these files you have to run
>>>> cgpsmapper first to convert to shapefiles).
>>>>
>>>> I used QGIS to examine the list of fields, and entered that list as the
>>>> dbfinfo line in the .dbfawk file. Unfortunately I couldn't get
>>>> XASTIR to
>>>> recognise my .dbfawk, so I moved the .dbfawk file to the maps directory
>>>> (to the same directory as the shapefiles) and gave it the same name
>>>> as the
>>>> shapefile. It worked.
>>>>
>>>> Today's quick experiment was to move the files *back* to the /config
>>>> directory and try and get them to work. When I did that XASTIR
>>>> reported
>>>> its "No DBFAWK signature for..." error, but then I selected Map|Index:
>>>> Reindex all maps, and viola! The .dbfawk files were found and used.
>>>>
>>>> The second thing I did was to edit the dbfinfo line and change all the
>>>> field names to uppercase (I already had them as lowercase). This
>>>> did not
>>>> seem to make a difference, which implies that the dbfinfo line in
>>>> .dbfawk
>>>> files is case-insensitive. I would like to verify this with the source
>>>> (or by asking someone who knows for sure).
>>>>
>>>> It might also be useful to point out that you can tweak the .dbfawk
>>>> files
>>>> while XASTIR is running. XASTIR reads them every time it re-draws the
>>>> map, so your changes are visible without having to quit and restart
>>>> XASTIR.
>>>>
>>>> Hope this is useful.
>>>>
>>>> 73,
>>>>
>>>> Andrew
>>>> ZL3AME
>>>>
>>>> _______________________________________________
>>>> Ozaprs mailing list
>>>> Ozaprs at aprs.net.au
>>>> http://aprs.net.au/mailman/listinfo/ozaprs
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Ozaprs mailing list
>>> Ozaprs at aprs.net.au
>>> http://aprs.net.au/mailman/listinfo/ozaprs
>>>
>>> _______________________________________________
>>> Ozaprs mailing list
>>> Ozaprs at aprs.net.au
>>> http://aprs.net.au/mailman/listinfo/ozaprs
>>>
>>>
>>>
>> _______________________________________________
>> Ozaprs mailing list
>> Ozaprs at aprs.net.au
>> http://aprs.net.au/mailman/listinfo/ozaprs
>>
>>
>
> _______________________________________________
> Ozaprs mailing list
> Ozaprs at aprs.net.au
> http://aprs.net.au/mailman/listinfo/ozaprs
>
> _______________________________________________
> Ozaprs mailing list
> Ozaprs at aprs.net.au
> http://aprs.net.au/mailman/listinfo/ozaprs
>
>
_______________________________________________
Ozaprs mailing list
Ozaprs at aprs.net.au
http://aprs.net.au/mailman/listinfo/ozaprs
More information about the Ozaprs
mailing list