| |
ZL3AI > APRDIG 04.05.03 18:45l 368 Lines 17518 Bytes #999 (0) @ WW
BID : 1223-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 24, 2/5
Path: DB0FHN<DB0ZWI<DB0HDF<DB0ERF<DB0SON<DB0MRW<OK0PPL<RZ6HXA<SP7MGD<VK7AX<
ZL2BAU<ZL3VML
Sent: 030427/1334Z @:ZL3VML.#80.NZL.OC #:64693 [Chch-NZ] FBB7.00i $:1223-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: WinAPRS/MacAPRS now supports TIGER map data
From: "Brian Webster" <bwebster@wirelessmapping.com>
Date: Thu, 24 Apr 2003 11:14:31 -0400
X-Message-Number: 9
Mark,
Couple of questions:
Will this new version still allow us to use the PMAP3.0?
Can we change the fonts on the tiger maps so they look a little easier to
read or is that a fixed function of the tiger data.
Do you have to be connected to the net full time for the tiger maps or can
you grab a map and save it on the local drive.
Can we turn off the mic-e conversion?
Brian, N2KGC
----------------------------------------------------------------------
Subject: RE: KISS mode PIC / stamp controller?
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Thu, 24 Apr 2003 15:31:07 -0000
X-Message-Number: 10
That's a handy tool. Doesn't help much for OpenTRAC, though - it's all
binary and you've got to specify the PID of 0x77. And there's nothing like
building a frame byte by byte to really find out how well you understand a
protocol. =]
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: WinAPRS/MacAPRS now supports TIGER map data
From: Robbie <mwrobertson@attbi.com>
Date: Thu, 24 Apr 2003 10:59:50 -0500
X-Message-Number: 11
Hi all,
My first impression is not very good, and I hope I am misunderstanding
this annoncement..
Are we to assume we have to download maps from TigerMaps to use with the
new release? If we are out in the field away from the internet, do we
have to know in advance to our locations and download appropriate maps?
Will these maps be zoomable, or does each level have to be downloaded?
Is developement to correct the 2.61 version to use Precision Mapping 5.0
ceased? Can we otherwise switch back to Pmap30 then?
I apologize if it sounds like I am complaining, but I think something
isn't quite right with the way I am understanding this..
Robbie, wa9inf
----------------------------------------------------------------------
Subject: Re: APRS Client Capabilities Chart (APRS-CCC?)
From: Alex <kr1st@amsat.org>
Date: Thu, 24 Apr 2003 12:22:24 -0400
X-Message-Number: 12
Curt Mills wrote:
>
>I know I'm going to take a beating for this, but then again, what do
>Icare? ;-)
You just needed something that makes Xastir look even better, we know..
:)
I really like it that you started with the price. That narrows down
choices to the most interesting choices rapidly. It will also show that
there's no correlation between the capabilities (and maybe even quality)
of a product and price, something which even fools experienced hams. If
there's a relationship, then it's probably inverse; the cheapest ones
have the most to offer for the money.
Excellent idea, Curt!
73,
--Alex KR1ST
----------------------------------------------------------------------
Subject: PMap 6.0 and MapTivate
From: Bill Diaz <william.diaz@attbi.com>
Date: Thu, 24 Apr 2003 11:30:16 -0500
X-Message-Number: 13
PMap 6.0
Undertow Software will be announcing the release of PMap 6.0 before long.
Exact details, pricing and licensing are not yet available. This version
will have the ability to use GDT data instead of US Census Bureau Tiger
Files.
The GDT data sets are much more accurate and detailed than Tiger Files. GDT
is constantly updating and correcting errors inherited from the Tiger
files. You can also obtain a quarterly update subscription that will
ensure that you have the latest street data available.
The GDT datasets are much larger than corresponding Tiger files. However,
the amount of detail, particularly in urban areas, is striking.
Existing APRS applications that use earlier versions of PMap can be updated
to 6.0 with a minimum of effort.
MapTivate
Undertow Software has announced MapTivate, an entirely new mapping
development OCX. MapTivate can use a highly optimized data set based on
Tiger data, or can use GDT data. GDT datasets for selected countries ou
tside the US are also available. In addition MapTivate can import shp,
Mid/Mif and georeferenced bmp, jpg and gif files. This ability can be used
to easily import point, polygon, and polyline data exported from popular
GIS applications or available for download from Internet sites. This is
ideal for display of NWS watches, warnings, and advisories.
The developer is provided with complete control of map rendering. This
includes specifying when and how map layers are rendered. If you don't
like the map colors or how and when the streets or labels are displayed,
you can change them to suit your needs.
I imported a Topo bitmap and then loaded street data on top of it. The
street layer overlayed the streets contained in the topo, but they extended
beyond the extents of the topo. You can also load the street layer under
the topo maps. Either way, the topo map becomes "smart". When you move
the mouse over the topo, you get street hints that display the street name
and address range etc. I added the ability to display the mouse position
in UTM, MaidenHead etc. This type of map would be ideal for SAR
applications.
MapTivate is not code compatible with PMap. Existing APRS applications can
be modified to work with MapTivate however.
If anyone is interested in seeing some screen dumps of MapTivate, or needs
additional information, feel free to contact me via E-Mail.
For the record:
I am currently under contract with UnderTow to perform initial beta tests,
and to develop demonstration applications in Visual Basic and Delphi.
Bill
----------------------------------------------------------------------
[commercial content deleted]
----------------------------------------------------------------------
Subject: Re: WinAPRS/MacAPRS now supports TIGER map data
From: Mark Sproul <msproul@jove.rutgers.edu>
Date: Thu, 24 Apr 2003 12:46:13 -0400
X-Message-Number: 15
Robbie
Like in previous versions, you have to install the maps that you want. Take
for example PM, you had to have the CD with you or you had to copy the
states that you want to your hard drive BEFORE you went out on a trip.
The map data is 100% vector, that is yes it is 100% zoomable and it scales
fantastically. The data is separated in most states, in a county by county
basis. Some states have large cities as separate files.
You can download ALL of the data, just the states you want, or just the
counties you want. The good news about this is if you want to run on an
older system that doesn't have a lot of disk space or memory, then you can
prune it down to just what you want. If you have any new lap top, then it
can easily handle all of the data.
If you take a look at http://www.winaprs.com/screenshots you will see
different areas of the country at different zoom levels, I think this does
a fairly good job of showing the ability to zoom in and out.
The other thing is this data is updated EVERY YEAR by the US Census Bureau,
additionally just this year, they have entered in a 200 million dollar/ 5
year contract with a private company to raise the data to even higher
standards.
Another thing I did not mention is you will have the full ability to custom
color your maps in any way you want. For example, the color of the rail
roads, the color of the water, the color of any of the 200 different
feature codes provided by the data. You can also customize the range at
which a particular feature shows up. The codes are fully documented within
the program so you know what things are, i.e. interstates vs state highways
vs local roads.
I have written all of this map drawing code totally from scratch over the
paste several months. It has been a lot of work getting the maps to look
nice and to be what I hope, very pleasing to everyone out there.
This new version should not be run on an outdated machine. If you try to
run it on a 200 mhz pentium, you will probably be disappointed. Since I got
the maps drawing properly, I have been able to do LOTS of things to speed
things up and have lots more planned for as soon as I can get to them (i.e.
after the Dayton release).
Mark
----------------------------------------------------------------------
Subject: Leasons learned in Northern KY - Re: Just trying to understand
From: "Jeff Thomas - KD4EVB" <kd4evb@hotmail.com>
Date: Thu, 24 Apr 2003 12:55:05 -0400
X-Message-Number: 16
Regarding Sean's e-mail...just FYI, W8MAP is probably the culprit, maybe
mixed in with a corrupted packet or the like making it appear to be from
W8APR.
I know for fact that this call has been a problem for a couple years now.
W8MAP used to have a just god awefull insane path set.
Last year I did some studies off one of our NKY digi's to see why the
locals were complaining about access times being ridiculous and a very
informative e-mail from a Lexington ham requesting if we'd consider
filtering off a few stations a few hundred miles out that were causing
problems. W8MAP (used to at least) was one of about 5-6 stations that we
filtered off at the digi's since out of about 200+ typical stations coming
through these 5 or so stations were responsible for 25-30% of the packets
coming in due to inconsiderate path settings/tx rates. I will not even
touch on the GATE and ECHO issues and abuse.
Many folks don't seem to understand how the path works, you'll see a lot of
folks running something like RELAY,WIDE,WIDE3-3 off bases (or even more
convoluted) and so forth versus the much shorter and efficient path of just
WIDE3-3 or maybe WIDE4-4.
Just some thoughts and notes from my experiences here in Northern KY, take
'em for what they are worth...probably not much :-) Opinions on APRS are
about as dime a dozen, and to top it off there is a ton of misunderstanding
and misleading info out there, so not trying to start a flame ware or the
like but if I irk a few folks off...I don't care ;-)
I think we can all agree that APRS in it's current form works, but is
quickly heading into a lot of problems related to the simple fact that 1200
baud 2 meter packet channels has a limit to what it can do. Combine this
with a UI unconnected nature of APRS, it only amplifies the problem. Mix
in users doing silly things, well go figure...amplify the problem say x100
:-) When the economy picks back up and amateur activity increases with it,
things are only going to get worse. I know of a lot of folks that have
pretty much given up on APRS as it's just too unreliable anymore, a few
have moved to other freq's (1.2k and 9.6k on 147.585, 441.0, and 446.5
being good examples). We've gained a lot of folks these last couple years,
but I think we've lost just about as many. I've been real close to moving
the digi to a another 1.2k or 9.6k freq myself several times, particularly
now that we could have a local I-gate if needed. Trust me it's been real
tempting to give up on 144.3900 since we've had good luck with 446.5 &
147.585 simplex APRS ops. Lot of the locals haven't used 144.3900 in ages
as they'd rather keep things local only and the speed and reliability of
the 'alternate' freq's is more important than range or i-gate access.
I'd suggest what many digi sysops have started doing across the country, or
at least some of this, especially in areas of high activity:
1. Remove WIDE digipeating, got WIDEN, TRACEN, and RELAY. The nature of
2m propagation in my area (and many others) causes a lot of dupes and loops
as I call 'em. Getting rid of the old inefficient WIDE protocol really
cleaned things up in my area. We left RELAY, WIDEn, KY, TRACEn in the digi
so properly configured mobiles passing through should be just fine. Even
if the mobiles are running something so horribly obsolete as RELAY,WIDE
they will still get one hop digi'ed.
2. Digi sysops, consider taking a laptop or put an old PC with some APRS
software at the digi site, put a minimal antenna on it (just enough that it
ONLY hears what is coming through the digi) and over a period of at least a
few days run all the logging you can. I'll almost bet that at every site
you'll find some 'interesting' things going on when you check over the
logs. You'll probably find a handful of stations that are always consuming
a very obvious disproportionate amount of air time without any explaination
(say a lot of messaging, being heard direct and digi'ed, an active mobile,
or the like to explain it) Usually always excessive tx rates often combined
with horrible path choices. HID ON often is a contributing factor.
3. Make the decision whether you want to try and contact the offending ops
with a friendly note to see if corrective action will be taken. After
seeing others try this over the years with little sucess (many hams have
egos bigger than their antenna's :-) I adopted a different approach. I
just filter 'em and move on. I figure this is somewhat controversial, but
hey it's your digi, your electricity, and with your call on it your
responsibility to keep things under control. Last I checked here in NKY we
are filtering off about half a dozen stations, never heard peep from these
guys (most are half a state away) and they are probably clueless. As a
digi sysop, my responsibility is to take care of things locally so that the
local users that support the digi's can use the system locally in an
effective manner and they stay off my back :-)
4. We've found that things work much more efficiently when everyone is
running WIDEn paths only. Just good ol' simple WIDE3-3 or WIDE4-4 works
great around here for both base and mobiles. We use TRACEn only for testing
and our digi's generate about a dozen or so TRACEn packets a day for some
of us local VHF/UHF weak signal folks use APRS to see band openings.
Opinions vary, but I tend to think anything beyond five hops is unjustified
except for unique short term situations were range is needed. My
philosophy is generally you only need the number of hops that it takes to
hit your local i-gate plus one hop at most, anything more than that is just
wasting channel bandwidth, and unlikely to get much further to begin with.
5. Since a lot of the software comes with an rather old path setting of
RELAY,WIDE for default (a subtle hint for the software writers), I
generally try to keep an eye out for new "locals" coming up on the channel
and drop them a friendly note offering suggestions on a much better path if
they are running the defaults. The default TX rates in a lot of the
software is pretty ridiculous also, back in the old days they were fine,
but not anymore.
I know I'll probably have some folks writing back to suggest DIGI_NED.
Frankly the stability of running DIGI_NED on a PC is very unattractive to
me. We have a PC based DIGI_NED digi nearby and it's down more than it's
up, last year it had not days, not weeks, but months worth of downtime.
Not trying to personally knock the digi or it's sysop, but the facts are
the facts....it's not something you want to count on IMHO, grin. I'm sure
others have had better luck, some have had bad luck. I've had some friends
out west try it and had the same problem. IMHO the KPC3+ is a effective
and reliable solution for a basic WIDEN digi or home station.
With the KPC3+'s setup right (and getting the setup just right takes
time...and opinions vary on how to do it) they just flat run and run and
run. They are also excellent for emergency/portable use as they can run
for hours on a simple 9v battery (very low power consumption). I've got
one that we installed about 6 months ago, never been back to the site other
than to check freq/deviation, 100% reliable. I've got another digi site
with a KPC3+ that has been up non-stop for just a few weeks short of 2
years, it would be nearly 4 years except I had to turn it off once for a
move to a different site! Occasionally I have the radio off or on low power
if I'm working one of the VHF contests at the site or doing tower/antenna
work, but the TNC has been on non-stop and has NEVER locked up. I've heard
from several sysops that have had them up for 3-5 years non-stop and heard
stories of guys being on their 2nd or 3rd digi radio but the same KPC3+.
Yeah, I know there are some EPROM based DIGI_NED solutions out there, but
they seem to be based on the MFJ TNC2 and I have heard more bad than good
on this setup. I run a 6m/220/440 node stack built on MFJ TNCs, trust me
this wouldn't be very reliabile either, grin.
Yeah, I agree that standardization is a good thing, but then again each area
is unique and some good solid standards with room for local tweaking would
do us all wonders. I know here in Kentucky and some surrounding areas it's
pretty much a free for all. Many of us here in Kentucky can't even remember
the last time we heard anything from the KY APRS coordinator, we've pretty
much had to hash things out ourselves. If it wasn't for the efforts of
TAWG, things would be even worse. I guess my only fear is that we've
allowed 144.3900 (from a big picture perspective) get so far out of control
already, it will probably never be brought back under control.
Constructive comments/discussion welcome, flames will find dev/null after
the first sentence, grin. Don't bother replying direct to my hotmail
address, due to the amount of spam I used to get, if you're not in my
address book...it gets auto-deleted. Feel free to look up my other e-mail
address on qrz.com if needed.
73 de Jeff, KD4EVB
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
