[aprssig] How to delete/remove an Object
ve7gdh at rac.ca
Thu Aug 14 13:20:08 EDT 2008
Bob WB4APR wrote...
> No, it was a fundamental principle of APRS. Operators must be able to
> mutually manage the APRS map. There are all kinds of things that can
> happen to a "station" that can cause his data to be wrong, in the
> wrong place, wrong info, bad info, inappropriate place, or info. Since
> that is a permanent part of the map, then anyone should be able to
> take over that station to correct the local situation map.
I can manage my map. I can "translate" the callsign or name of an object
to anything I want it to be, but only I see that. I can delete a station
(on my map) if I wish, but it will of course show up on my map when it
next beacons. I can exclude it (on my map) if there is some reason to. I
can take over and edit an object created by someone else. I can also
delete it once I own it. It will of course show up again if the original
owner beacons it again. What I can't do (and don't think I should be
allowed to do) is "take over" a station. I can certainly create an
object with the same "name" as an existing station, but UI-View
differentiates between stations and objects... remember the colon and
semi-colon. If they were to be treated exactly the same, there wouldn't
be a character that defined it as a position report or as an object. On
this principal, we differ in opinion.
> Remember two other details:
> 1) If anyone takes over that "station" as an object, the new ownership
> is clearly attributible to that new operator, so there is no problem
> with loss of attribution.
Well, I can create an object the same name as the callsign in an
existing position report, but one is a position report (I guess what we
have been calling "statioins" in this discussion), so I can't see what
is the difference between that and what you are describing... except I
take it that you are saying that anyone should be able to "take over a
station" and tell everyone else to delete it from the map and instead
use the newly created object that you created. Or did I
mis-understand... perhaps you weren't saying that I (or anyone else)
should be allowed to delete a station and tell everyone else to delete
> 2) If the original Station is still on the air, then his software
> remains on the air and continues to transmit his original info. In
> that sense, you cannot replace him with an object. Because of the
> fundamental =equivalence= of stations and objects, his retransmissoin
> from his "station" will always take back-over any OBJECT attempt to
> replace him.
I can't replace a station with an object. I can create an object with
the name the same as the callsign in an existing station though. On my
map (UI-View) they can co-exist.
> But if his last transmitted STATION info that is stuck on the map from
> an hour, a day, a month ago is in the way, or not appropriate for the
> current event, then anyone should be able to update that "station"
> with an OBJECT that then replaces that "station" on all clients so
> that it can be MOVED or deleted. That was fundamental to APRS map and
> situational awareness management.
I thought that APRS was supposed to present current information. The
default expiry time in UI-View is 60 minutes, but I have mine set for 90
minutes. I think you offered an opinion a while back that 80 minutes
would be a good time if I remember correctly. To see data from a month
ago, I would have to set the expire time to zero, in which case nothing
would expire. I would be very often seeing old / stale / out-of-date
information. Other than entering zero, 9999 seconds or 166.65 minutes,
or about 2 3/4 days.
Again, I can place an object on the map. I can't take over or delete
another station other than deleting it from my own map. Hopefully there
would never be a case of another ham maliciously deleting stations /
objects (in your world) but in my world, at least a position report
would be inviolate.
> I mean that I never see APRS objects used to the extent the system was
> designed for at APRS events. And I attribute that to the problems in
> managing and transmitting and updating large numbers of objects in
> UIview which is the most used APRS program these days.
OK, but I don't see the lack of objects (on your map or mine) as having
anything to do with the ability to take over another station or turn it
into an object instead of a position report.
> Thanks. Yes, I know at first blush people panic at the thought of
> abuse of this feature. But it is not abused, and is a powerful
> fundamental principle of APRS.
I don't believe I have eve seen anyone maliciously delete an object.
> And you canot take over or replace a working station.
I must have completely misunderstood your previious message. I thought
you were saying that I should be able to do exactly that... if I was
using another APRS client. Perhaps you were saying that an object of the
same name should replace a station (position report) until such time as
the real station beaconed again?
Again, in UI-View both can co-exist on the map. One is a position report
and the other is an object. However, if you were using APRSdos (and was
within earshot of me) and I was using UI-View and I beaconed an object
with the same name as a station on your map, wouldn't it just replace it
on your map?
> The only reason I keep raising these issues is so that people do not
> forget what APRS is supposed to do so that when new applications are
> written they do not make the same mistakes as in the past.
I've got to agree with you completely there. From one of your recent
postings, I take it that "the APRS spec" and all of the erratas and
additions are going to be put into one updated document. That will
definitely be a major help for anyone writing a new APRS client. Not
that I'm going to become a software author, but I'll be one of the first
> Not complaining, just making we sure we do not forget how APRS is
> supposed to work...
Anything can be improved, but I think that it works pretty well. The
APRS spec is only the spec because we call it that. If everything you
are describing is put down in the spec, at some point in time someone
will write an APRS client that works exactly the way you want it to
73 es cul - Keith VE7GDH
"I may be lost, but I know exactly where I am!"
More information about the aprssig