[aprssig] POI engine on APRS-IS (OBJ engine IS required)

[Steve Noskowicz]

--- Lynn W. Deffenbaugh (Mr) wrote:
> POI isn't new to non-technical APRS users.  They've
> probably used a navigation GPS and know what a POI is. 

I dunno'. I'm pretty much just an ordinar'  joe schmuck Ham and I have heard about APRS Objects, but never heard of a POI until this discussion.


> They may or may not be APRS-literate enough 

APRS DOES require some level of smarts and education (on APRS), though I agree the less (pre-defined knowledge) you require, the better..


...many APRS appliance users ...don't know the
> difference between a station, an object, an item, or
> anything else.

I dunno'   Objects are pretty well talked about in the literature, so to speak.  I never heard of Items until mentioned here...and don't say read the spec.  I'm an Engineer and it's not an easy read at all...too many bits and bytes shoe-horned into odd places to get this functionality or that, to get an Engineer to understand, much less an appliance user.

  Much of this is over my head, but expecting an applicance user to specify a symbol is asking a lot.  I, certainly, would need a printout of symbols in my pocket.  What about letting the text do the work of the symbol to let 'whomever' know what it is for, and have a generic 'OBJ' symbol.  yea, I know that's an addition to the table, or use some vanilla symbol already there.  

  Unless i missed it, not unlikely since I tend to skim, I haven't seen comments on just what this is to be used for that is special.  I'd like to see a list of uses that require this type of a feature.  THen some of these proposed features/parameters might be better bracketed.

  An Object, or Kenwood poseud-Object is sorta' easy to understand for us Joe Schmucks.  Remember the confusion with the fundamental operation of the CQ Server? (and I thought it was obvious)

  I'm siding with Lynn's stuff below.  Have a basic function with enhancements for the Gurus amongst yall. 
 Yea, Yea.  KISS me you fool.  (;-)

RE: Adoption vs. same name problem.
  If this is a message, then wouldn't the OBJ server *know* if another station sent an OBJ message with the same OBJname and not reposition the original'  However if the entire APRS-IS keys only on the name, this is an issue for sure.  The water's getting a bit too deep for me....  Getting a reply saying that your OBJ anme is taken sounds like a good fix, since messages have re-tries.

-- 
73, Steve, K9DCI, Joe Schmuck.


> Why so cryptic?  Why not just a message to POI that
> says "OBJCTNAME comment" for the simple case.  And if
> they want something other than the default X symbol (/.),
> then "OBJCTNAME [st] comment".  Done. Simple to
> remember, yet flexible as well.
> 
> Oh, and for the advanced users, they can start the comment
> with CSE/SPD if they want to provide that.
> 
> And for the VERY advanced users, they can use [/\]
> CSE/SPD/BRG/NRQ or use the DFSshgd for an Omni DF. 
> This level of user would be going out on a special mission
> and can brush up on the advanced format before leaving
> home.
> 
> But the general mobile user can simply key in a message to
> POI that says "I95CRASH 3 Miles before Exit 25" without
> having to remember or enter anything complex.  KISS
> 
> >> Retransmission of the object after the originator
> has moved can be
> >> handled by the POI server doing a dupe-detect on
> the defining request
> >> to keep the object where it was for a given message
> sequence.
> > Agree.  The retries will have the same message
> number, so they are dupes.
> 
> At least this part works to avoid re-defining objects from a
> moving originator.  But it DOES require that the
> original message contain a sequence number, or even the
> owner will lose the ability to move an object without
> changing something in the description or it'll still
> (possibly) look like a dupe.  We're not talking a 30
> second dupe detect window here because we're trying to
> dupe-detect retransmissions which, by definition, will be
> longer than that time.
> 
> >> I still contend that we need an explicit ADOPT flag
> to prevent
> >> inadvertent movement of objects between users
> across the global scale.
> > The overtaking of objects is fundamental to APRS. 
> It was designed that way.
> > Users are repeatedly educated to this issue and those
> who intend to make
> > meaningful use of this function should be well aware of
> their need to make
> > object names unique.  I do not think we should be
> adding layers upon layers
> > of tweaks to get around things-people-can-do
> incorrectly.
> 
> It's not a tweak, it's a designed-in protection, IMHO. 
> A single object originator will never need to know
> this.  If the object ID is in use, the POI server will
> respond with instructions on how to force the
> adoption.  Being aware of the need to make names unique
> is one thing.  Being ABLE to determine uniqueness when
> in the field under pressure is quite another.  Whatever
> the remote server can do to protect the user from making
> mistakes is a good thing.
> 
> >> Just because one event has a FOOTSORE object, a new
> FOOTSORE object
> >> somewhere else on the planet should NOT
> automatically move the object
> >> unless the new owner really intended the adoption.
> > That's how APRS works.  And it is beyond this
> SERVER's responsibility to
> > correct these errors.  Though I do admit that when
> the design was
> > formalized, the APRS-IS was not a primary design
> factor, local RF was.  If
> > we want to resolve these issues in Clients on the
> APRS-IS, then that is a
> > different issue.  For example, all clients that
> drink from the global
> > firehose might consider an OBJECT DUPE RANGE parameter
> that will not replace
> > a previous object if the new object of the same name
> AND *Case* comes in
> > more than XXX miles from the existing location. 
> But again, that is at the
> > clients where the overwriting decision is made, not in
> the APRS-IS.
> 
> I'm not proposing the server to correct an error, but to
> assist the operator in not making an error in the first
> place.  APRS-IS is now a reality and we've got the
> opportunity to take the global picture into account in
> current and future designs.  If the expected user is
> not expected to be in a position to make the proper
> uniqueness determination, then I believe the server should
> help.
> 
> >> Automatic creation of existing object is especially
> bad in the UI-View
> > world...
> > 
> > If UIview has a fundamental flaw that does not allow
> the on-air adoption by
> > the latest owner (A fundamental APRS precept), then
> that is something that
> > needs to be addressed at the UIVIEW level.
> 
> The issue is not only local RF, but the global extension of
> local RF via the -IS.  And that extension might be just
> out of RF earshot so no amount of "don't override unless far
> enough away" is determinable because far enough might still
> be too close and vice versa.
> 
> You know as well as I do that anything in UI-View cannot be
> "addressed" any more.  But where possible and
> convenient, why not account for it?
> 
> >> Adoption is good at the local level (maybe), but
> when the object
> >> definitions hit the global APRS-IS, things get ugly
> fast.
> > Agree.  So can my suggestion above be used? 
> That is, each client may
> > introduce an object-dupe-limit to use when it makes
> these decisions?  The
> > APRS-IS is not involved.  It is only a deliverly
> mechanism.  It is always
> > the client that has to make the overwrite.  Though
> I do not know how APRS.FI
> > will implement this.  Othern than have maybe a
> typical VHF range limit of
> > say 200 miles or 300 km?
> 
> Even 200 miles may be too close for some adoptions and too
> far for others.   I still believe that a
> remote user needs the larger visibility provided by the
> server to avoid stepping on an existing object, and maybe
> the server can even suggest how far away that object is from
> the requester, but I believe the requester should explicitly
> ask for the adoption if s/he doesn't already own the
> object.
> 
> Objects are currently created by APRS clients with more
> global visibiltiy and can therefore make a local uniqueness
> determination easily and safely.  If the POI server is
> moving this out to a limited visibility RF-only client, I
> believe the check and confirmation should be
> made.   The server should still support
> adoption by a new owner, but it should not be automatic,
> IMHO.
> 
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile
> and Win32
> 
> PS.  I might be swayed to accept OBJ instead of POI,
> but I'd like some others to weigh in on recognizability and
> rememberability before it is finalized.
> 
> > 
> > 
> > Bob, Wb4APR
> >