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

Re: [aprsisce] request for change in object placement algorithm (more non-overlapped object names)

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.