Loading ...
Sorry, an error occurred while loading the content.

request for change in object placement algorithm (more non-overlapped object names)

Expand Messages
  • D. Daniel McGlothin KB3MUN
    Lynn, I d like to suggest a change in how the placement algorithm for locating multiple objects at the same location. Currently, the algorithm places multiple
    Message 1 of 10 , Aug 16, 2013
    Lynn,

    I'd like to suggest a change in how the placement algorithm for locating
    multiple objects at the same location.

    Currently, the algorithm places multiple objects in a pattern around the
    object location, 3 to the left, 3 to the right, and one each above and
    below. See also attached screenshot. Once the ninth (or later) object
    for that position is mapped, they are overlayed (with transparent)
    background on the object at the 3 o'clock postion.

    I am working at applying APRStt (see
    http://www.aprs.org/aprstt/aprstt-coding25.txt ) as a means of doing a
    triathlon event team progress reporting using the DTMF tones to locate a
    runner/team at a particular checkpoint. This APRStt would be an adjunct
    to the regular voice net. We will have somewhere between 50 and 100
    teams at the event.

    However, I may have more than 9 objects at a particular checkpoint.
    Would it be possible to implement at least one more 'ring' of objects
    around that position before overwriting any. Ideally, the cluster of
    objects at that location would simply grow as the number of objects
    grew, and shrink as the objects are moved to another checkpoint. I
    would be willing to live with 'holes' in the object location matrix.

    I mentioned 50 to 100 teams. If possible, all 100 objects could be
    visually displayed; however, a 6x6 or 6x8 matrix would likely suffice.

    The desired visual effect is similar to the visual appearance of the "TT
    Corral" discussed in that APRStt spec (search for "The TT-CORRAL:", just
    over halfway thru the document), but applied at any object positions.


    I probably explained the request poorly, so please ask if I didn't
    convey enough information.


    73 de Daniel KB3MUN
  • Lynn W Deffenbaugh (Mr)
    I understand your request perfectly, but let me say upfront that it s not likely to happen due to performance constraints. What you are visually seeing is
    Message 2 of 10 , Aug 16, 2013
    • 0 Attachment
      I understand your request perfectly, but let me say upfront that it's not likely to happen due to performance constraints.  What you are visually seeing is nowhere near as simplistic as you describe.

      But before describing what is really going on under the covers, try checking Configure / Screen / Labels / Allow Overlap to see what your screen COULD look like.  That configuration option is there because of the performance concerns.  If you turn it on, labels are just placed to the right of stations, regardless.  This saves a TON of processing overhead resulting in much lower CPU consumption which saves battery life as well.  This same performance concern is why labels disappear if there are more than Configure / Screen / Labels / Max Visible.. on the screen.  (Incidentally, your 50-100 stations will probably crack the default value of that limit as well).

      Now, a correction to your description.  APRSISCE/32 doesn't place objects anywhere except centered on their transmitted coordinate.  It's the LABELs that are shuffled around relative to the station's symbol, not the "object" itself.  And while the labels appear to go around a central coordinate as you describe, that's not quite what they're doing.

      Note: the following occurs every single time the screen is drawn by APRSISCE/32.  It doesn't "remember" anything from one screen update to the next, simply because a small change in one station's position can have a ripple effect on the outcome (yes, I know this from lots of original testing of the algorithm).

      It its simplest form, what APRSISCE/32 attempts to do is to place labels such that they do not overlap any station icon or label that's already on the screen.  I call it "label overlap avoidance".

      The labels, as you have noted, have several possible places that they can land, actually 8 possibilities, each of which are checked until one is found to not overlap anything that has already been placed on the screen.  These are: 1) Center right, 2) Center left, 3) Bottom right, 4) Top right, 5) Bottom left, 6) Top left, 7) Bottom Center, 8) Top Center, just as your attachment showed: 

      But the magic part of that is determining "not overlap anything".  To do that, APRSISCE/32 has to keep track of everything on the screen and how much of the screen it covers!  It does this using a Win32 API construct called a "region" which is composed of rectangles delimited by left/right/top/bottom coordinates.  There are APIs to add rectangles to the region which is done every time a station symbol is drawn, which is the first pass of painting.  As soon as the number of stations painted exceeds the "Max Visible..." limit, APRSISCE/32 stops maintaining the region to avoid unnecessary overhead (the only thing that uses the region is label placement).

      After all stations have been drawn, if there aren't too many stations on the screen, the labels are done.  For each station, the entire label (remember, you can have more than just the station ID in your label) text is determined.  Then the rectangle required to draw that label in the current default font is calculated (yes, there's a Win32 API for that).  With the required screen space required in hand, APRSISCE/32 begins asking if the various placements of that rectangle overlaps any portion of the region.  For crowded spaces on the screen, this means that 1, then 2, then 3, then 4, then ... 8 different rectangles are compared to the region, LOTS of overhead when you consider the complexity of the region by that point in time.  Once a free space has been located, or back to (1) if they all overlap, the label is painted and it's final resting place is also added to the region.

      But performance isn't the only reason I'm loath to change the algorithm.  Once you move away from "adjacent" to the station's symbol, it gets really, REALLY hard to determine just what the label is referring to!  You can actually see this happen due to (what I consider to be) a defect in my current algorithm that might eventually get fixed (if I can afford the overhead).  In the following screen-shot, which WX station is KB1ATL?



      It's not very clear, is it?  You might find it even harder to fathom that it's actually the right-most one of the set of three that are almost in a line.  Below the "p" in 89F 1mph SSW and above the "6" in DW5926.  So, what's it doing so far away from the symbol?  It's trying to avoid everything that was on the screen before it, including what it THOUGHT was the placements for 4 (top right) and 6 (top left).  But why did 8 (top center) move it so far up?  Well, it tried to avoid the two-line-high label positions so it got way out there.  I really should move outwards a line (or even a pixel) at a time rather than by the entire size of the label.  But consider the iterative overhead in THAT form of label placement!  And there's no Win32 API to "find the closest place that this rectangle is not in that region".  Bummer.

      And that's just my point at resisting adding yet more label placements that aren't "attached" or snuggled up against the station symbol.  When I saw just how far away the current 7 and 8 options would be, I determined that I really needed to stop there or things would get seriously out of hand.

      And that's my concern with your suggestion.  It'd be (relatively) easy if I was implementing the TT-corral (which I did, incidentally, in the RFID reader object placement algorithm which predated the TT-corral, but my corral also avoided placing objects where APRS mobile stations may have been when the RFID was read) where I KNEW that all of the stations were actually co-located at a single point, but that's not really what's going on inside APRSISCE/32 as you can read above.

      The label overlap avoidance applies, not only to a stack of stations at a single point, but also to stations close enough for their labels to overlap like the four below:



      If I were simply applying avoidance to a single point, these labels would all be to the right of the station and you'd have a visual mess like:

      APRS.FI:

      Yes, that's what I saw before implementing the label overlap avoidance, and this happens FAR more often, but invisibility thanks to 1-8, on the APRS landscape than a stack of stations at a single point.  And the right screen shot shows that aprs.fi even overlaps a single line station ID label.  You should inject your objects into the APRS-IS and see what your cluster looks like at aprs.fi.

      As my final point, I would contend that if you have more than 8 labels (and a second loop would increase that by a lot more than just 8 when you consider the available screen estate in an expanding circle), you probably wouldn't be able to find the one you're looking for anyway.

      If you need to know where a station is, just do a Screen / Follow / Find, enter the ID and pop open a View / None MultiTrack so you can see just that one single station.  Putting more than 3 or 4 (maybe 7 extrapolating from http://tinyurl.com/7digits) labels around a single point is just counter-productive.  In fact, I might even consider just dropping the labels if I get to 8 and still haven't found space.  The reason I haven't done that to date is that it further masks the fact that there's a serious pile-up of stations whereas a black blob of a label to the right at least provides a bit of that indication.

      You have a well described request, but I hope you now realize the reasoning behind my response.  But like a lot of things from the wild days of APRSISCE/32 development, you never know what might happen once I've had a change to cogitate on this a bit (although THIS one I've been thinking about recently already in a parallel development)

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      PS.  Like how about just shrinking the font size of the labels to allow more to crowd around a single space?  Well, that would require not only knowing what space has been occupied (the region) but what is actually occupying it to go back and (iteratively) start shrinking fonts to see how much I could cram into a limited space.  Ug.

      PPS.  The easiest way to see just how dynamic the current overlap avoidance algorithm is, zoom out to where stations are pretty crowded but labels are still show and pan around a bit.  You'll see labels jumping all over the place as various stations enter and leave the displayed space.  That's how I found the weather station example above.

      On 8/16/2013 2:20 PM, D. Daniel McGlothin KB3MUN wrote:
      <*>[Attachment(s) from D. Daniel McGlothin KB3MUN included below]
      
      Lynn,
      
      I'd like to suggest a change in how the placement algorithm for locating 
      multiple objects at the same location.
      
      Currently, the algorithm places multiple objects in a pattern around the 
      object location, 3 to the left, 3 to the right, and one each above and 
      below.  See also attached screenshot.  Once the ninth (or later) object 
      for that position is mapped, they are overlayed (with transparent) 
      background on the object at the 3 o'clock postion.
      
      I am working at applying APRStt (see 
      http://www.aprs.org/aprstt/aprstt-coding25.txt ) as a means of doing a 
      triathlon event team progress reporting using the DTMF tones to locate a 
      runner/team at a particular checkpoint.  This APRStt would be an adjunct 
      to the regular voice net.  We will have somewhere between 50 and 100 
      teams at the event.
      
      However, I may have more than 9 objects at a particular checkpoint. 
      Would it be possible to implement at least one more 'ring' of objects 
      around that position before overwriting any.  Ideally, the cluster of 
      objects at that location would simply grow as the number of objects 
      grew, and shrink as the objects are moved to another checkpoint.  I 
      would be willing to live with 'holes' in the object location matrix.
      
      I mentioned 50 to 100 teams.  If possible, all 100 objects could be 
      visually displayed; however, a 6x6 or 6x8 matrix would likely suffice.
      
      The desired visual effect is similar to the visual appearance of the "TT 
      Corral" discussed in that APRStt spec (search for "The TT-CORRAL:", just 
      over halfway thru the document), but applied at any object positions.
      
      
      I probably explained the request poorly, so please ask if I didn't 
      convey enough information.
      
      
      73 de Daniel KB3MUN
      
      
      <*>Attachment(s) from D. Daniel McGlothin KB3MUN:
      
      <*> 1 of 1 Photo(s) http://groups.yahoo.com/group/aprsisce/attachments/folder/294637652/item/list 
        <*> APRSISCS32 multi objects arranged at a single location.jpg
      
      ------------------------------------
      
      Yahoo! Groups Links
      
      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/aprsisce/
      
      <*> Your email settings:
          Individual Email | Traditional
      
      <*> To change settings online go to:
          http://groups.yahoo.com/group/aprsisce/join
          (Yahoo! ID required)
      
      <*> To change settings via email:
          aprsisce-digest@yahoogroups.com 
          aprsisce-fullfeatured@yahoogroups.com
      
      <*> To unsubscribe from this group, send an email to:
          aprsisce-unsubscribe@yahoogroups.com
      
      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/
      
      
      

    • Lynn W Deffenbaugh (Mr)
      Just for completeness, here s the scene below without the label overlap avoidance: At least you can see (if you study it long enough) which station KB1ATL is!
      Message 3 of 10 , Aug 16, 2013
      • 0 Attachment
        Just for completeness, here's the scene below without the label overlap avoidance:



        At least you can see (if you study it long enough) which station KB1ATL is!  And that the other two in that line are CWnnnn stations, but talk about UGLY!  And this, as I stated originally, happens all over the map which is why labels avoid everything and don't really cluster around a single point (other than moving around their own station to avoid anything else on the screen).

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

        On 8/16/2013 3:39 PM, Lynn W Deffenbaugh (Mr) wrote:
        In the following screen-shot, which WX station is KB1ATL?



        It's not very clear, is it?  You might find it even harder to fathom that it's actually the right-most one of the set of three that are almost in a line.  Below the "p" in 89F 1mph SSW and above the "6" in DW5926.  So, what's it doing so far away from the symbol?  It's trying to avoid everything that was on the screen before it, including what it THOUGHT was the placements for 4 (top right) and 6 (top left).  But why did 8 (top center) move it so far up?  Well, it tried to avoid the two-line-high label positions so it got way out there.  I really should move outwards a line (or even a pixel) at a time rather than by the entire size of the label.  But consider the iterative overhead in THAT form of label placement!  And there's no Win32 API to "find the closest place that this rectangle is not in that region".  Bummer.

      • D. Daniel McGlothin KB3MUN
        ... I suspected not. ;) I am relatively unfamiliar with the breadth and depth of capabilities APRSISCE/32 offers, but did anyway choose it as a mapping engine
        Message 4 of 10 , Aug 16, 2013
        • 0 Attachment
          On 8/16/2013 15:39, Lynn W Deffenbaugh (Mr) wrote:
          > I understand your request perfectly, but let me say upfront that it's
          > not likely to happen due to performance constraints. What you are
          > visually seeing is nowhere near as simplistic as you describe.

          I suspected not. ;)

          I am relatively unfamiliar with the breadth and depth of capabilities
          APRSISCE/32 offers, but did anyway choose it as a mapping engine for
          some events we are planning to run with APRStt. We will be using a
          newly developed APRStt mode with DTMF strings like *bbnnn# indicating
          that runner/team has reached checkpoint bb. The checkpoint is the item
          that determines the lat/long position, the runner is the object label
          that moves from one checkpoint to another.


          > ...Configure / Screen / Labels / Allow Overlap...
          > ...Configure / Screen / Labels / Max Visible...

          I will look into this more.


          > Now, a correction to your description. APRSISCE/32 doesn't place
          > objects anywhere except centered on their transmitted coordinate. It's
          > the LABELs that are shuffled around relative to the station's symbol,
          > not the "object" itself. And while the labels appear to go around a
          > central coordinate as you describe, that's not quite what they're doing.

          Thanks for the proper vocabulary.



          > It its simplest form, what APRSISCE/32 attempts to do is to place labels
          > such that they do not overlap any station icon or label that's already
          > on the screen. I call it "label overlap avoidance".

          [snip of valuable explanation of the process, but I did pick out the
          next portion]

          > But the magic part of that is determining "not overlap anything". To do
          > that, APRSISCE/32 has to keep track of everything on the screen and how
          > much of the screen it covers! It does this using a Win32 API construct

          I would offer that for an event specific mapping tool, I can provide the
          mapping engine just the packets I want it to have; assure that the
          object labels to be located have a uniform format; and can accept that
          exact placement is not desired as much as approximate location of all
          object labels (trading exact placement for full visibility).

          I could even 'make' my event course a single linear 'line' with
          checkpoints far enough apart that object labels clearly fit
          unambiguously 'near' the object's position.

          The intended use is a visual overview of the event for the net control
          station managing the event communications, for the event staff, and for
          the family/friends of the contestants.

          Would a single or double column of (maybe alphabetized, or maybe by
          order of entry to the checkpoint) object labels at the position be
          reasonable. Said column(s) could be left or right of the object
          position. I understand this might add 'stateful awareness' to the process.

          An alternate would be to craft a matrix based on the team/runner number
          that is the APRS packet's object. A 3 digit runner number nnn could be
          viewed as a column (nnn \ 100) and a row (nnn % 100) and that matrix
          roughly centered over the checkpoint position.

          I am assuming a special 'mode' of mapping operation for the above, and
          am willing to accept that it is not really what mainstream APRS mapping
          is all about. But then my APRS interest is trackerless event progress
          reporting.

          We will likely use APRSISCE/32 as out mapping tool for our OCT-2013
          adventure triathlon in the mountains of Caledonia State Park & Michaux
          State Forest (east of Chambersburg, PA). And use that 'find' feature
          you mentioned to locate an individual when necessary.

          A couple of parting questions as I go off to experiment.

          When an overlapped object label is no longer overlapped, does that label
          on the bottom of the heap eventually bleed thru as visible once again?

          Are you aware of any other APRS mapping tool that would approach the
          type of behavior I'm looking for? And if not, would you be willing to
          mentor me (my day-job is machine tool programming) should I choose to
          craft such a tool?

          Oops, that was 3 questions. ;)

          Thanks again for your answers, and also for the APRSISCE/32 mapping
          application.

          73 de Daniel KB3MUN
        • Lynn W Deffenbaugh (Mr)
          Short (and somewhat cheeky) answer: You need the APRStt engine to not create the objects at a single configured point, but to keep track of how many are at
          Message 5 of 10 , Aug 16, 2013
          • 0 Attachment
            Short (and somewhat cheeky) answer:

            You need the APRStt engine to not create the objects at a single
            configured point, but to keep track of how many are at that point and
            which slots are occupied and create the object within a lat/lon-offset
            corral as the specification describes. That way EVERY viewer would be
            able to see the objects in the grid, provided that they are looking with
            a suitable zoom layer. This is what the RFID reader/object creator did
            (and still does if anyone sets up an RFID reader).

            Or you need someone to write a more intelligent object-distributing
            APRStt engine... But to do it well, it would need to monitor everything
            going on and auto-distribute objects within the "corral".

            Or maybe someone could write an APRStt object "watcher" that would pick
            up the APRStt-created objects at a given point and "relocate" them (via
            APRS of course) to a grid-like layout configured for each point. As a
            matter of fact, this would probably be the path of least resistance and
            has the added advantage that every APRS viewer would again "see" the
            objects.

            Does the APRStt engine put the objects out via RF or only via APRS-IS?
            The last proposal would pretty much need to be -IS based due to the
            traffic that could be generated, although you probably need to be -IS
            based anyway for that same reason, 50-100 participants arriving at a
            station is a lot of traffic...

            Longer answer will follow after I consider it a bit more.

            Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

            On 8/16/2013 8:38 PM, D. Daniel McGlothin KB3MUN wrote:
            > On 8/16/2013 15:39, Lynn W Deffenbaugh (Mr) wrote:
            >> I understand your request perfectly, but let me say upfront that it's
            >> not likely to happen due to performance constraints. What you are
            >> visually seeing is nowhere near as simplistic as you describe.
            > I suspected not. ;)
            >
            > I am relatively unfamiliar with the breadth and depth of capabilities
            > APRSISCE/32 offers, but did anyway choose it as a mapping engine for
            > some events we are planning to run with APRStt. We will be using a
            > newly developed APRStt mode with DTMF strings like *bbnnn# indicating
            > that runner/team has reached checkpoint bb. The checkpoint is the item
            > that determines the lat/long position, the runner is the object label
            > that moves from one checkpoint to another.
            >
            >
            >> ...Configure / Screen / Labels / Allow Overlap...
            >> ...Configure / Screen / Labels / Max Visible...
            > I will look into this more.
            >
            >
            >> Now, a correction to your description. APRSISCE/32 doesn't place
            >> objects anywhere except centered on their transmitted coordinate. It's
            >> the LABELs that are shuffled around relative to the station's symbol,
            >> not the "object" itself. And while the labels appear to go around a
            >> central coordinate as you describe, that's not quite what they're doing.
            > Thanks for the proper vocabulary.
            >
            >
            >
            >> It its simplest form, what APRSISCE/32 attempts to do is to place labels
            >> such that they do not overlap any station icon or label that's already
            >> on the screen. I call it "label overlap avoidance".
            > [snip of valuable explanation of the process, but I did pick out the
            > next portion]
            >
            >> But the magic part of that is determining "not overlap anything". To do
            >> that, APRSISCE/32 has to keep track of everything on the screen and how
            >> much of the screen it covers! It does this using a Win32 API construct
            > I would offer that for an event specific mapping tool, I can provide the
            > mapping engine just the packets I want it to have; assure that the
            > object labels to be located have a uniform format; and can accept that
            > exact placement is not desired as much as approximate location of all
            > object labels (trading exact placement for full visibility).
            >
            > I could even 'make' my event course a single linear 'line' with
            > checkpoints far enough apart that object labels clearly fit
            > unambiguously 'near' the object's position.
            >
            > The intended use is a visual overview of the event for the net control
            > station managing the event communications, for the event staff, and for
            > the family/friends of the contestants.
            >
            > Would a single or double column of (maybe alphabetized, or maybe by
            > order of entry to the checkpoint) object labels at the position be
            > reasonable. Said column(s) could be left or right of the object
            > position. I understand this might add 'stateful awareness' to the process.
            >
            > An alternate would be to craft a matrix based on the team/runner number
            > that is the APRS packet's object. A 3 digit runner number nnn could be
            > viewed as a column (nnn \ 100) and a row (nnn % 100) and that matrix
            > roughly centered over the checkpoint position.
            >
            > I am assuming a special 'mode' of mapping operation for the above, and
            > am willing to accept that it is not really what mainstream APRS mapping
            > is all about. But then my APRS interest is trackerless event progress
            > reporting.
            >
            > We will likely use APRSISCE/32 as out mapping tool for our OCT-2013
            > adventure triathlon in the mountains of Caledonia State Park & Michaux
            > State Forest (east of Chambersburg, PA). And use that 'find' feature
            > you mentioned to locate an individual when necessary.
            >
            > A couple of parting questions as I go off to experiment.
            >
            > When an overlapped object label is no longer overlapped, does that label
            > on the bottom of the heap eventually bleed thru as visible once again?
            >
            > Are you aware of any other APRS mapping tool that would approach the
            > type of behavior I'm looking for? And if not, would you be willing to
            > mentor me (my day-job is machine tool programming) should I choose to
            > craft such a tool?
            >
            > Oops, that was 3 questions. ;)
            >
            > Thanks again for your answers, and also for the APRSISCE/32 mapping
            > application.
            >
            > 73 de Daniel KB3MUN
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • D. Daniel McGlothin KB3MUN
            ... Cheeky is fine. It is often humorous, too. ... I realize that someone might have to be me. The watcher route would probably be my initial choice, too.
            Message 6 of 10 , Aug 16, 2013
            • 0 Attachment
              > Short (and somewhat cheeky) answer:

              Cheeky is fine. It is often humorous, too.



              > You need the APRStt engine to not create the objects at a single
              > configured point, but to keep track of how many are at that point and
              > which slots are occupied and create the object within a lat/lon-offset
              > corral as the specification describes. That way EVERY viewer would be
              > able to see the objects in the grid, provided that they are looking with
              > a suitable zoom layer. This is what the RFID reader/object creator did
              > (and still does if anyone sets up an RFID reader).
              >
              > Or you need someone to write a more intelligent object-distributing
              > APRStt engine... But to do it well, it would need to monitor everything
              > going on and auto-distribute objects within the "corral".
              >
              > Or maybe someone could write an APRStt object "watcher" that would pick
              > up the APRStt-created objects at a given point and "relocate" them (via
              > APRS of course) to a grid-like layout configured for each point. As a
              > matter of fact, this would probably be the path of least resistance and
              > has the added advantage that every APRS viewer would again "see" the
              > objects.

              I realize that someone might have to be me.

              The 'watcher' route would probably be my initial choice, too.



              > Does the APRStt engine put the objects out via RF or only via APRS-IS?
              > The last proposal would pretty much need to be -IS based due to the
              > traffic that could be generated...

              My answer is potentially limited to the Byonics APRStt offering. My
              answer is also limited by my ignorance of APRS in general--I've only
              recently stepped out of the "Anyway, why do I need APRS to tell me where
              my truck is?" camp. ;)

              Where the APRS packets are gated to depends largely on how the equipment
              is lashed-up.

              The APRStt engine is capable of sending the packets to an arbitrary RF
              channel on. IF that channel's radio is on 144.39 Mhz, the packets
              eventually (assuming sufficient digipeaters and igates) reach the
              internet databases--this, I believe, is what you refer to by '-IS'
              sourced packets. IF that channel is not 144.39 MHz, then I would have
              to take responsibility for a local database, which would still be your
              '-IS' source.

              I could have the APRSISCE/32 be listening to the APRStt engine's RF
              output, wherever it is set frequency-wise. In that case, I believe the
              packet source would be what you call 'via RF'.

              The APRStt engine is also capable of sending the packets out a serial
              port so that I could capture them and send them anywhere, even into the
              serial in of the APRSISCE/32 program. Then it wouldn't matter. Except
              that I have no remembered state in event of power failure.

              It is that latter issue, remembering state across potential power
              interruptions that is a significant concern.

              The event held where there is likely little internet connectivity (ham
              radio is used because it works where FRS or CB radios, cell phones,
              satellite phones DO NOT work. Even with ham radio, we often need to
              have two operational nets simply due to the terrain.

              Maybe you already have some magic that solves the 'remembering the past'
              so that when things get powered up again we could either replay that
              'past' or pickup from with the mapping state 'current' when the power
              went down.

              In any case, given that the packet could be re-formed by a 'watcher'
              application at any of the interfaces, the object's 'location' could be
              massaged to cluster or corral them 'correctly'.



              > ...although you probably need to be -IS
              > based anyway for that same reason, 50-100 participants arriving at a
              > station is a lot of traffic...

              In my event, at least, all the participants will be at the start line at
              the beginning of the event. The event is orchestrated to intentionally
              initially spread the participating teams out so that it is not like a
              marathon (the largest group together for much of the event). After the
              start, typically, 2 to 5 teams may pass a checkpoint at about the same
              time, more often single teams arrive with 1 to 5 minutes between
              arrivals. Depending on how they are counted (some checkpoints locations
              are passed several times), we have about 2 dozen unique checkpoints.

              [Oops, I'll also need to account for that feature of passing a
              checkpoint multiple times--looks more like the linear course visual
              layout works better all the time.]

              The event is 6 hours long, with the individual team performance spread
              between 4 and 6 hours for covering the course.

              I would anticipate using a computer to pre-load the system with all team
              objects located at the start line well before the event starts.

              We will not be using the tracking feature to time the event or
              individual team performance. Approximate timestamps will be useful for
              knowing when the 'lost' team has passed the a checkpoint. That
              approximate timestamp will help locate the probable radius (or more
              likely the cone of probable location) should we need to go hunting.
              This traceability requirement suggests some benefit to a team's object
              label always appearing in the same relative order in a cehckpoint
              cluster/corral.

              Currently we do this all by voice nets, and the NCS is quite busy. We
              are looking to reduce the NCS load, as well as increase visibility for
              the observers.


              > Longer answer will follow after I consider it a bit more.

              I appreciate your thinking on this matter. The event is not 'til late
              OCT. ;) In any case, we will use what is available for this year as we
              prove out the APRStt DTMF reporting side of things.

              As I said, I recognize this feature request, like APRStt, is not
              mainstream APRS, and thus necessarily subject to a limited audience.



              > ...This is what the RFID reader/object creator did
              > (and still does if anyone sets up an RFID reader).

              Tell me more about this RFID thingy, or point me to a link. Is this
              that APRSrfid concept Bruninga showcases at
              http://www.aprs.org/aprs-rfid.html and
              http://www.aprs.org/rfid/RFID-spec.txt ?

              I'm eventually going to considering using something like this for
              unattended checkpoints.


              73 de Daniel KB3MUN
            • Lynn W Deffenbaugh (Mr)
              (Here s the longer answer) ... I m honored that you ve selected APRSISCE/32 for this event and will do what I can to help it work out well for you. I did see
              Message 7 of 10 , Aug 16, 2013
              • 0 Attachment
                (Here's the longer answer)

                On 8/16/2013 8:38 PM, D. Daniel McGlothin KB3MUN wrote:
                > I am relatively unfamiliar with the breadth and depth of capabilities
                > APRSISCE/32 offers, but did anyway choose it as a mapping engine for
                > some events we are planning to run with APRStt. We will be using a
                > newly developed APRStt mode with DTMF strings like *bbnnn# indicating
                > that runner/team has reached checkpoint bb. The checkpoint is the item
                > that determines the lat/long position, the runner is the object label
                > that moves from one checkpoint to another.

                I'm honored that you've selected APRSISCE/32 for this event and will do
                what I can to help it work out well for you.

                I did see the recent message traffic about APRStt moving objects to
                fixed points, but have been busy with a new development, so I didn't pay
                close attention to it. If I understand your request properly, it seems
                that the APRStt engine puts all objects at a single lat/lon per
                checkpoint? It doesn't do any sort of distribution or round-robining of
                those objects near the checkpoint? e.g. it doesn't do any corralling,
                just putting them all at a single point.

                >
                >> But the magic part of that is determining "not overlap anything". To do
                >> that, APRSISCE/32 has to keep track of everything on the screen and how
                >> much of the screen it covers! It does this using a Win32 API construct
                > I would offer that for an event specific mapping tool, I can provide the
                > mapping engine just the packets I want it to have; assure that the
                > object labels to be located have a uniform format; and can accept that
                > exact placement is not desired as much as approximate location of all
                > object labels (trading exact placement for full visibility).

                That's quite a lot of assurances...

                > I could even 'make' my event course a single linear 'line' with
                > checkpoints far enough apart that object labels clearly fit
                > unambiguously 'near' the object's position.

                Did I mention that one thing I absolutely despise are subway maps that
                bear little to no relation to the actual geographical placement of the
                stations? This proposal is very similar.

                But to parallel the RFID object placement algorithm again, the
                configuration of the RFID reader (transmitting as an object description
                by the reader itself) describes where objects should be created both as
                relative offset from the reader's lat/lon but also providing an
                increment lat/lon and rows/colums for the "corral" within which objects
                should be generated. No need to put the course into a linear line if
                you can tell each checkpoint where its corral should be located and shaped.

                > The intended use is a visual overview of the event for the net control
                > station managing the event communications, for the event staff, and for
                > the family/friends of the contestants.

                Understood, but wouldn't it be better if any/(nearly)all APRS viewers
                (like aprs.fi for those viewers at home) would be able to see what's
                going on and not just the main event net control station?

                > Would a single or double column of (maybe alphabetized, or maybe by
                > order of entry to the checkpoint) object labels at the position be
                > reasonable. Said column(s) could be left or right of the object
                > position. I understand this might add 'stateful awareness' to the process.
                >
                > An alternate would be to craft a matrix based on the team/runner number
                > that is the APRS packet's object. A 3 digit runner number nnn could be
                > viewed as a column (nnn \ 100) and a row (nnn % 100) and that matrix
                > roughly centered over the checkpoint position.
                >
                > I am assuming a special 'mode' of mapping operation for the above, and
                > am willing to accept that it is not really what mainstream APRS mapping
                > is all about. But then my APRS interest is trackerless event progress
                > reporting.

                You're talking about some seriously data-dependent coding here, and it
                all falls apart when someone doesn't follow the assumptions. Still not
                likely to be done in the main APRSISCE/32, but don't be too disappointed
                yet.

                > We will likely use APRSISCE/32 as out mapping tool for our OCT-2013
                > adventure triathlon in the mountains of Caledonia State Park & Michaux
                > State Forest (east of Chambersburg, PA).

                I grew up in Johnstown, PA (until college), but never got over to
                Chambersburg much. We'd go through Bedford to Breezewood and the hop on
                70 to come south much more often.

                > And use that 'find' feature
                > you mentioned to locate an individual when necessary.

                Find will definitely answer quite a few questions, of that I can assure
                you. Individual MultiTracks centered on points of particular interest
                will also be invaluable, I can imagine.

                > A couple of parting questions as I go off to experiment.
                >
                > When an overlapped object label is no longer overlapped, does that label
                > on the bottom of the heap eventually bleed thru as visible once again?

                As I mentioned, the label overlap avoidance occurs on every single
                screen paint. Label placement is very dynamic based on what is where
                and how much is visible at every given instant. The only thing that
                isn't very predictable is the order in which stations and their labels
                are painted. IIRC, it's likely to be alphabetical order from bottom to top.

                > Are you aware of any other APRS mapping tool that would approach the
                > type of behavior I'm looking for? And if not, would you be willing to
                > mentor me (my day-job is machine tool programming) should I choose to
                > craft such a tool?

                Nope. Well, maybe. There's a new kid fixing to join the APRS client
                fray and eventually it would be able to do practically anything you can
                envision (and code). But it's not likely to be generally available in
                time for this event, but we might be able to work something out off list.

                > Oops, that was 3 questions. ;)

                That's ok, I can't count either. That's what I have computers for!

                > Thanks again for your answers, and also for the APRSISCE/32 mapping
                > application.

                You're welcome on both counts. Like I said, I'm sure something can be
                worked out to help ensure the successful use of APRStt for this event.

                Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
              • Lynn W Deffenbaugh (Mr)
                ... Where are the APRStt TT4s located? At the checkpoints, in a repeater shack? Or what RF receiver are they getting their TouchTones from? ... Good battery
                Message 8 of 10 , Aug 16, 2013
                • 0 Attachment
                  On 8/16/2013 10:04 PM, D. Daniel McGlothin KB3MUN wrote:
                  >
                  > The APRStt engine is also capable of sending the packets out a serial
                  > port so that I could capture them and send them anywhere, even into the
                  > serial in of the APRSISCE/32 program. Then it wouldn't matter. Except
                  > that I have no remembered state in event of power failure.

                  Where are the APRStt TT4s located? At the checkpoints, in a repeater
                  shack? Or what RF receiver are they getting their TouchTones from?

                  >
                  > It is that latter issue, remembering state across potential power
                  > interruptions that is a significant concern.

                  Good battery backups on the PC and then check out Configure / Save
                  Posits which will record every current stations location (not track)
                  when APRSISCE/32 is closed and will automatically recall them when
                  restarted. If you have a few minutes between failure and shutdown,
                  you're covered. Even with your database idea, you'll need to provide
                  some sort of power protection.

                  > Maybe you already have some magic that solves the 'remembering the past'
                  > so that when things get powered up again we could either replay that
                  > 'past' or pickup from with the mapping state 'current' when the power
                  > went down.

                  Yep, Save Posits.

                  > Currently we do this all by voice nets, and the NCS is quite busy. We
                  > are looking to reduce the NCS load, as well as increase visibility for
                  > the observers.

                  I can only imagine how busy it would be to do this by hand!

                  > > ...This is what the RFID reader/object creator did
                  > > (and still does if anyone sets up an RFID reader).
                  >
                  > Tell me more about this RFID thingy, or point me to a link. Is this
                  > that APRSrfid concept Bruninga showcases at
                  > http://www.aprs.org/aprs-rfid.html and
                  > http://www.aprs.org/rfid/RFID-spec.txt ?
                  >
                  > I'm eventually going to considering using something like this for
                  > unattended checkpoints.

                  Yes, that's the stuff. If you configure an RFID reader as he describes,
                  and register RFID tags via APRS messages, and all of this is gated to
                  the APRS-IS, it works today. The RFID server-side is running on my
                  server and will automatically translate RFID reads into object
                  placements based on what the RFID reader's comment string says. The
                  server-side works, it's always getting reliable RFID reads that is the
                  issue.

                  Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
                • D. Daniel McGlothin KB3MUN
                  Lynn, ... I would put as many up as necessary. We usually need to relay messages or to run 2 voice nets to provide adequate course coverage. Careful planning
                  Message 9 of 10 , Aug 16, 2013
                  • 0 Attachment
                    Lynn,


                    >> The APRStt engine is also capable of sending the packets out a serial
                    >> port so that I could capture them and send them anywhere, even into the
                    >> serial in of the APRSISCE/32 program. Then it wouldn't matter. Except
                    >> that I have no remembered state in event of power failure.
                    >
                    > Where are the APRStt TT4s located? At the checkpoints, in a repeater
                    > shack? Or what RF receiver are they getting their TouchTones from?

                    I would put as many up as necessary. We usually need to relay messages
                    or to run 2 voice nets to provide adequate course coverage.

                    Careful planning is yet to come, but my initial inclination scatter
                    sufficient APRStt engines about, have them feed via a beam antenna the
                    NCS station. Then that NCS station would digipeat the info to the
                    start/finish line.

                    That statement of the plan is obviously embryonic. Autonomous local
                    behaviors for when the linkages breakdown would need to be defined. And
                    among other things, we would need to engineer the RF footprint of the
                    event (both terrain and frequencies). The current voice net is
                    typically done using 2m simplex, we already engineer this afresh each
                    year as no prior course has yet to be exactly repeated.



                    >> It is that latter issue, remembering state across potential power
                    >> interruptions that is a significant concern.
                    >
                    > Good battery backups on the PC and then check out Configure / Save
                    > Posits which will record every current stations location (not track)
                    > when APRSISCE/32 is closed and will automatically recall them when
                    > restarted. If you have a few minutes between failure and shutdown,
                    > you're covered. Even with your database idea, you'll need to provide
                    > some sort of power protection.

                    Understood. But then stuff still happens.

                    I used to be involved with business disaster planning and recovery. I
                    soon concluded that business continuity planning was mostly a matter of
                    deciding how much paranoia you could afford.



                    >> Maybe you already have some magic that solves the 'remembering the past'
                    >> so that when things get powered up again we could either replay that
                    >> 'past' or pickup from with the mapping state 'current' when the power
                    >> went down.
                    >
                    > Yep, Save Posits.

                    That is the hint I was looking for.



                    >> > ...This is what the RFID reader/object creator did
                    >> > (and still does if anyone sets up an RFID reader).
                    >>
                    >> Tell me more about this RFID thingy, or point me to a link. Is this
                    >> that APRSrfid concept Bruninga showcases at
                    >> http://www.aprs.org/aprs-rfid.html and
                    >> http://www.aprs.org/rfid/RFID-spec.txt ?
                    >>
                    >> I'm eventually going to considering using something like this for
                    >> unattended checkpoints.
                    >
                    > Yes, that's the stuff. If you configure an RFID reader as he describes,
                    > and register RFID tags via APRS messages, and all of this is gated to
                    > the APRS-IS, it works today. The RFID server-side is running on my
                    > server and will automatically translate RFID reads into object
                    > placements based on what the RFID reader's comment string says. The
                    > server-side works, it's always getting reliable RFID reads that is the
                    > issue.

                    Currently, at the manned checkpoints, the teams get a card punched.
                    Each station verifies that card is punched in order--else the team gets
                    to go find the missed checkpoint.

                    Thus a GO/NOGO audible and visual signal could be worked into the
                    process to simulate the good read and act as the card-punch. I'm not
                    yet ready to suggest the checkpoint sequence audit be done at these
                    remote stations.

                    BTW, given the late OCT timeframe, and the altitude, a primary concern
                    at the manned checkpoints is hypothermia of the participants. But that
                    doesn't prevent the course planner from having them wade streams or do
                    inflatable raft challenges.

                    Not too long ago, a pre-dawn course for 'advanced' teams was a map &
                    compass orienteering challenge where 5 unmanned checkpoints rewquired
                    the teams to get a card punch from punch hanging on the 'flag'. So
                    unmanned but reporting stations would be likely viewed as an advantage,
                    but only a supplement to the manned stations. Eventually, we could
                    consider putting the RFID stations in lieu of hams if participation
                    drops off.


                    73 de Daniel KB3MUN
                  • D. Daniel McGlothin KB3MUN
                    Lynn, ... Unhuh. I have direct control over my expectations, and over the object name. I ll backup a bit with that first assurance, and restate it to say that
                    Message 10 of 10 , Aug 16, 2013
                    • 0 Attachment
                      Lynn,

                      >>> But the magic part of that is determining "not overlap anything". To do
                      >>> that, APRSISCE/32 has to keep track of everything on the screen and how
                      >>> much of the screen it covers! It does this using a Win32 API construct
                      >>
                      >> I would offer that for an event specific mapping tool, I can provide the
                      >> mapping engine just the packets I want it to have; assure that the
                      >> object labels to be located have a uniform format; and can accept that
                      >> exact placement is not desired as much as approximate location of all
                      >> object labels (trading exact placement for full visibility).
                      >
                      > That's quite a lot of assurances...

                      Unhuh.

                      I have direct control over my expectations, and over the object name.

                      I'll backup a bit with that first assurance, and restate it to say that
                      by using a 'private' event frequency for the APRS packet traffic (i.e.,
                      something simplex and NOT 144.39 MHz), I can reasonably expect that the
                      only packets received are event related; the APRStt decaying message
                      repeat functions delivers most of the rest of that 'assurance'.



                      >> I could even 'make' my event course a single linear 'line' with
                      >> checkpoints far enough apart that object labels clearly fit
                      >> unambiguously 'near' the object's position.
                      >
                      > Did I mention that one thing I absolutely despise are subway maps that
                      > bear little to no relation to the actual geographical placement of the
                      > stations? This proposal is very similar.

                      A shared abhorrence. But maybe a necessary compromise.


                      > ...No need to put the course into a linear line if
                      > you can tell each checkpoint where its corral should be located and shaped.

                      The telling is easier than the doing.

                      Tell: center the corral on the object position.

                      Do: Dynamically build the corral by treating the fixed format team
                      number (the object name) as an index into the corral. [I think I'm
                      about to repeat myself here.]





                      > You're talking about some seriously data-dependent coding here, and it
                      > all falls apart when someone doesn't follow the assumptions. Still not
                      > likely to be done in the main APRSISCE/32, but don't be too disappointed
                      > yet.


                      In this case, it is the event planner/executor, namely me and my
                      buddies, that will need to assure those assumptions. We've managed to
                      send structured DTMF messages with out HTs, maybe we can manage a few
                      additional rules.



                      > Understood, but wouldn't it be better if any/(nearly)all APRS viewers
                      > (like aprs.fi for those viewers at home) would be able to see what's
                      > going on and not just the main event net control station?

                      I could always encourage them to use APRSISCE/32, couldn't I?

                      Especially since I cannot get, for example, aprs.fi to show packets the
                      way I want from an APRStt event last week. Maybe someone can tell me
                      how to get displayed on any of the internet APRS sites the all of the
                      objects timestamped on 10-AUG-2013 from these queries:

                      http://aprs.fi/?c=raw&call=KB3MUN&limit=300&view=normal
                      http://aprs.fi/?c=raw&call=N3QBI-7&limit=300&view=normal

                      Or maybe don't tell me. I'll be playing with APRSISCE/32 for now.



                      I suspect that all the APRS mappers have some means of exposing info
                      about overlapped objects. Even UI-View has such an option.



                      But, I suppose, what you are really implying is having an single event
                      web-page that the remote audience can point their browser to and have
                      all the details silently managed for them.








                      > Find will definitely answer quite a few questions, of that I can assure
                      > you. Individual MultiTracks centered on points of particular interest
                      > will also be invaluable, I can imagine.

                      I'll spend bit of time getting to know APRSISCE/32 quite a bit better.




                      73 de Daniel KB3MUN
                    Your message has been successfully submitted and would be delivered to recipients shortly.