[aprssig] How to delete/remove an Object

[Keith VE7GDH]

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 
it too?

> 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 
downloaders!

> 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 
work.

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"