[aprssig] Re: TIGER maps what-s the problem?

[VE7GDH]

Bob WB4APR wrote...

> Ah, THe problem is when you SEND a message from a new
> location and someone then tries to send you back an
> ACK or a REPLY from the APRS-IS. Most APRS-IS
> servers will not allow the messages to flow back to the
> local IGate if the reported position for that sending
> station is not valid or is not in the filter list of the local IGate

I getcha. One of my tests was via TCPIP. My second test was via RF to a 
station that was within range, either direct or via a digi. I was really 
just trying to prove or disprove whether I could send a message from UI-View 
without a position entered and whether the message via RF would get gated or 
not and show up at findu.com. There probably aren't too many UI-View 
stations out there without a valid position entered or a GPS attached. I do 
realize the original thread was really about sending a message from a D7 
without a valid position entered. For the record, I could send a message 
from UI-View and it would be gated even if the originating station didn't 
have a position. A reply or ACK via the APRS-IS would not work out very 
well!

> Thanks for the test, but your test did not test that function.
> Yes, everything gets to FINDU.  But only messages go
> back to RF if an IGate recognizes a local station AND
> the SERVER that it is connected to recognizes the
> station as within the range filter of that IGate.

OK... I guess you are really just saying that stations should send a valid 
position. This is pretty normal for most APRS use.

> WIthout being in the station list, doesnt that prevent the
> callsign from being recognized for most other functions, such
> as search or find, etc?

That is true. To be honest, the ONLY position-less beacons I am used to 
seeing are from a TinyTrak 3 or OpenTracker when they are first powered up 
with a GPS that doesn't have a lock yet. The situation usually takes care of 
itself as soon as the GPS gets a lock. Do you perhaps see more 
"position-less" stations in your neck of the woods? <g>

> That makes it a precise position, when you the sender
> did not intend it to be at that precise location. What if that
> precise location is in a bordello and  your wife  is checking
> to see that your airplane landed in St Louis?

I do understand that ambiguity is a feature that is in the APRS spec. It 
doesn't bother me in the LEAST that I can't enter an ambiguous position in 
one particular APRS client. I don't know if I'm more "situationally aware" 
than most people, but I always have a map, compass and GPS pretty close. 
Rest assured, if I was at a bordello, the position would be either entered 
with no ambiguity or with the help of a GPS. I wouldn't want my wife to 
worry needlessly that I didn't know exactly where I was!

> That is the kind of problem that should not exist in
> APRS, or any kind of GIS system. The integrity of the
> ambiguity of the source of data should be maintained
> all the way through the system to any viewer. This
> was fundamental to APRS, but some programs ignored
> it. Thus, users of those progams should be aware of
> the potential for missinterpretation...

If a program or hardware device is capable of entering an ambiguous 
position, and the user wants to or needs to enter an ambiguous position, let 
them do it. I don't see it as a problem. I think it's great that ambiguity 
is in the spec. I'm not concerned that not all APRS clients can enter an 
ambiguous position. To tell you the truth, I would be far more concerned 
with the lack of integrity of a proper position than an ambiguous position. 
To me, something that is "fundamental to APRS" is something that would make 
it all fall apart and not work if it wasn't done. To me, ambiguity is 
something that is in the spec... not something that is fundamental.

> And hopefully authors of future code will include this
> fundamental in their programs.

I too would encourage authors to include things that are in the spec. Just 
like the APRS spec should evolve and change if changes are needed, so should 
programs change. To me, it just isn't the end of the world if a little-used 
feature isn't implemented in a particular APRS client.

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"