[aprssig] Object Classification

[Chris Walker]

After some further investigation and pondering...

*********************************************************************************
This is just a proposed solution and should not be used until approved.
*********************************************************************************

I think the best solution to object classification would be to use the
destination address.

While some "object generators", stations that generate large numbers
of objects in an automated fashion, may use this field in some way to
signify information, it does not seem to be standardized.

I propose the following format

AX.25/APRS Destination address:
first character: O (the letter oh, for Object [class], I do not think
there are any 'Beacon" addresses in this namespace.)
2nd - 4th characters: Object class, such as QKE (earthquake), WXA
(weather alert), etc.
5th - 6th characters: optional, 2 character ISO country code (ISO
3166-1 alpha-2), although optional, use is strongly recommended if
possible and sensible. For example if a station is generating
earthquake objects for the entire world it would be preferable to
include the country code in objects that represent earthquakes that
occurred within the proximity of a country. This will allow consumers
of the objects to filter them by region.

Some examples:

Weather Alerts generated for United States: OWXAUS
Weather Alerts generated for Australia: OWXAAU
Weather Alerts generated for Canada: OWXACA
Earthquake object generated for United states OQKEUS
Earthquake object occurring in the middle of the ocean away from a country: OQKE

__________


This provides several advantages:

Filtering that is more robust, simpler, and durable than is possible
today, which requires multiple techniques based on hard coding
originating station, data format, symbology  or a combination of all
three. For example if a user wants US weather alert objects today, an
APRS-IS filter might be: "-e/WXSVR-AU t/n" which translates to NWS
Weather & Weather Objects (t/n. weather objects are uniquely
identified this way but not other classes of objects), and exclude the
weather objects from Australia (-e/WXSVR-AU). This method works but is
rather brittle, if additional weather alerts are generated for other
countries, it breaks.

Durability, even if a station that is generating objects of a certain
class goes silent and is replaced by another station, the filtering
and classification is not affected. An alternate filter for US weather
objects is to specify "e/AE5PL-WX", this suffers from the coding of a
particular station. AE5PL-WX replaced WXSVR for generating US weather
alerts.

APRS-IS filtering: using the UNPROTO u/ filter with wildcards provides
a simple way to request objects of a certain class. For example
u/OWXAUS would filter US weather alert objects and exclude all others.
u/OWXA* would receive all weather alerts for all countries.


Any comments Bob? or anybody else?

Chris Walker
KD7YAQ


And to keep the conversation contained in one thread my original post
of the subject:

However I see a growing problem, that of a growing number of CLASSES
or CLASSIFICATIONS of objects and no explicit information in the
objects for differentiation.

For example, weather alert objects, have two things in common, the
station that injected them into APRS-IS and the format of the data.

Both are sub-optimal for classification, on one hand if the
originating station is coded as a filter and the station changes, the
method fails, if the station injects other types of objects the
classification fails.

The data format as well is sub optimal, for example I received a ISS
object that looked just like a weather alert down to the Multiline
Object Format superficially looking valid.

Another example are Earthquake Objects, which suffer from the same
problem of hard coding an originating stations or relying on the
symbol information. The symbol information would seem like a good
idea, except any user can use an Earthquake symbol (and in many
applications a user may not even know it is an earthquake symbol,
because there is no text describing the symbol to the user)....there
is at least one user near Austin, TX who is using the earthquake
symbol as a station identifier.

In summary, even though it adds another layer of management, a way to
classify objects of a certain type, i.e. Weather Alerts, Earthquakes,
or Satellite Positions, would be useful. It would allow applications
to simply filter objects that the user is interested in.

The question is how to encode the classification information in an
unobtrusive way as possible. Unfortunately, considering the data
format for weather alert objects, I can't think of a way that is
backward compatible.

Perhaps a way of using the symbol data in an overloaded way is
possible, a classified object could simply use a single bit set to one
to signify that the symbol data can be trusted for classification as
opposed to being a symbol just randomly selected by a user for some
other meaning.