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

Re: [aprsisce] request for change in object placement (LIST)

Expand Messages
  • Robert Bruninga
    For large numbers of runners, there may not be a practical solutionon the map. Maybe we need to think outside the box. The purpose of this is to keep track
    Message 1 of 2 , Aug 17, 2013
    • 0 Attachment
      For large numbers of runners, there may not be a practical solutionon
      the map. Maybe we need to think outside the box. The purpose of this
      is to keep track of runners. And we know that all runners are on the
      course, so we really dont need a cluttered map to find them.

      Why not make an all new function that simply watches for all object
      names with a pre-defined event PREFIX and then simply LIST them with
      Checkpoint and TIME. Done

      RUNNER MILE TIME

      The APRStt engine will have an event specified PREFIX which is added
      to all runner objects and so it will be trivial to snag these and add
      them to a SORTED list making it easy to find a runner.

      It would seem that this is a better desired result for keeping track
      of runners than cramming so many numbers on the map at thse fixed
      points.

      A cute feature of this list could be that when you cursor over a
      runner number in the list, that a LINE is drawn to the actual map
      location. Or a color circle could highlight the location.

      Bob, Wb4APR

      On Sat, Aug 17, 2013 at 12:56 AM, D. Daniel McGlothin KB3MUN
      <kb3mun@...> wrote:
      > 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
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    • Robert Bruninga
      Nevrmind, Im reading email backwards and see that you are already discussing the LIST solution as we did in RFID. Yes, that is exactly what I had in mind.
      Message 2 of 2 , Aug 17, 2013
      • 0 Attachment
        Nevrmind, Im reading email backwards and see that you are already
        discussing the LIST solution as we did in RFID. Yes, that is exactly
        what I had in mind.

        Bob, WB4APR

        On Sat, Aug 17, 2013 at 9:27 AM, Robert Bruninga <bruninga@...> wrote:
        > For large numbers of runners, there may not be a practical solutionon
        > the map. Maybe we need to think outside the box. The purpose of this
        > is to keep track of runners. And we know that all runners are on the
        > course, so we really dont need a cluttered map to find them.
        >
        > Why not make an all new function that simply watches for all object
        > names with a pre-defined event PREFIX and then simply LIST them with
        > Checkpoint and TIME. Done
        >
        > RUNNER MILE TIME
        >
        > The APRStt engine will have an event specified PREFIX which is added
        > to all runner objects and so it will be trivial to snag these and add
        > them to a SORTED list making it easy to find a runner.
        >
        > It would seem that this is a better desired result for keeping track
        > of runners than cramming so many numbers on the map at thse fixed
        > points.
        >
        > A cute feature of this list could be that when you cursor over a
        > runner number in the list, that a LINE is drawn to the actual map
        > location. Or a color circle could highlight the location.
        >
        > Bob, Wb4APR
        >
        > On Sat, Aug 17, 2013 at 12:56 AM, D. Daniel McGlothin KB3MUN
        > <kb3mun@...> wrote:
        >> 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
        >>
        >>
        >>
        >> ------------------------------------
        >>
        >> Yahoo! Groups Links
        >>
        >>
        >>
      Your message has been successfully submitted and would be delivered to recipients shortly.