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
  • 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 1 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.