>>> 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 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
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
> 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:
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