| |
ZL3AI > APRDIG 11.02.04 04:45l 194 Lines 9172 Bytes #999 (0) @ WW
BID : 2814-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 08, 2/4
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<IK1ZNW<ZL2TZE<ZL3VML
Sent: 040211/0235Z @:ZL3VML.#80.NZL.OC #:18855 [Chch-NZ] FBB7.00i $:2814-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: No more RELAY,WIDE defaults for fixed stns
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sun, 08 Feb 2004 11:40:29 -0500
X-Message-Number: 6
Since fixed stations should not generally use a path starting with
RELAY,... we want to encourage all sofware to remove such defaults from
their code. Here is the current status?
APRSDos = Wide,Wide <confirmed 2004
WinAPRS = Relay,Wide <unconfirmed
APRS+SA = Relay,Wide <unconfirmed
APRSPoint = Relay,Wide <unconfirmed
PocketAPRS = Relay,Wide <relay is OK for mobile/portable.
UI-View = none <confirmed 2004
Xastir = Wide <new as of 2004
Yes, all software was encouraged to use relay many years ago, but these
days it is not good as a default for fixed stations.
Thanks, Bob, WB4APR
----------------------------------------------------------------------
Subject: topographical maps
From: Matt Murphy <web8ck@yahoo.com>
Date: Sun, 8 Feb 2004 09:13:58 -0800 (PST)
X-Message-Number: 7
Is there an APRS program that supports topographical maps?
=====
Matthew, kc8bew
kc8bew@qsl.net
----------------------------------------------------------------------
Subject: APRS MapManager
From: Steve Dimse <k4hg@tapr.org>
Date: Sun, 8 Feb 2004 12:24:11 -0500
X-Message-Number: 8
As promised, here is more on my plans for a mapping infrastructure. Please
note that this design goes beyond just meeting the needs of findU, I see
this as an opportunity to make all of APRS easier and more useful.
There is no such thing as a perfect map. All maps are compromises, since
they represent a large, three dimensional object on a small, flat piece of
paper (or computer screen). Different maps make different trade-offs in
parameters like size, scale, projection, detail, and type of data
displayed. The trick is finding the best map for a given situation.
APRS MapManager (APRS MM) is a project designed to provide a mapping
infrastructure for the APRS community. For those geographical areas with
detailed shapefile availability, a MapServer based system, like that
employed by APRSworld, or built in shapefile support, as in Xastir, is a
good solution to obtaining detailed maps. Even in such areas though, there
are times when a user may want to have a less detailed map...these can
focus attention on the objects being represented rather than on the map.
There are also image based maps that can be very useful, such as topo,
radar, and aerial images.
At the center of the project is a database containing details about maps,
not the maps themselves. There is nothing new about this idea, from the
earliest days of APRS, Bob's APRSdos embodied this concept, allowing the
program to automatically select the map most appropriate for a given view.
Where this proposal is new is that it will handle many disparate types of
maps, and rather than a database on each individual computer, it aims to
create a central repository for these map details, and for some types of
maps, the maps themselves. APRS clients and indivual users would be free to
grab any or all of the database and map library for their own use.
Examples of the map types that could be handled include APRSdos, palmAPRS,
WinAPRS, TIGER, images, and APRSworld maps. The system will have built in
caching for those maps requiring a lot of CPU or bandwidth to generate.
The details of the maps are entered in through a librarian interface, the
plan being that a small number of people will serve as librarians,
receiving map submissions from users, validating them, and adding them to
the database. The maps themselves would be stored on disk, in areas
acceible through http.
The database and map dorectory will be mirrored on more than one server,
most likely on the two findU servers and the APRSworld server should Jim
wish to participate, providing the needed redundancy. Furthermore, since
the code and database will be released under the GPL, any user wishing to
keep a local copy will be able to do so. The database will be in MySQL, the
programming in Perl, and since these run under Mac OS, Unix, Linux,
Windows, and other OSes, this is a cross-platform solution.
In the most common use, the users of the system (which generally comprise
APRS client programs) will make a request for a map, specifying an area to
be covered, and one or more parameters specifying the level of detail, or
some other characteristic, like a nautical chart, weather radar, topo map,
and so on. It could also specify a specific type of map, like WinAPRS,
palmAPRS, or APRSdos. The result would either be returned as an image of
the rendered map, or the map data iteslf.
A user could also query the database to find particular maps...say someone
needed an palmAPRS map of San Paulo...at present this would be something
that would send a person to Google, at best a hit or miss proposition. With
APRS MM, one would use a simple web interface to perform the search, and
then download the desired map with a single click.
Client programs like Xastir, WinAPRS, and UI-View could be updated to use
the database automatically, performing the searches and downloading maps to
a local hard disk with little difficulty, or using the online generation to
generate the images of the maps. This will be particularly useful to people
wishing to write new APRS programs...there will not be a need to write all
the map routines from scratch.
APRS maps are usually represented in files as vectors, the system will be
able to serve the original format, for example if a user wished to have a
WinAPRS map on their own computer. Most requests though are likely to be
for the drawn image of a map. These will be served in the form of geo files
understood by Mac/WinAPRS, Xastir, findU, and others. I'd like to support
the INF format used by UI-View, but that format does not include a URL, it
is meant to be a file that resides in the same folder with the same name as
the image. Rager states things like this are handled by external
applications in his system, so perhaps someone will write one to support
geo files. Embedded within the GEO file is the URL for the image...in other
words, when it processes a request for a map, the program will produce the
image and place it in a temporary directory on the web server, and return
the geo file as the http data. The program, in turn, is able to use the
embedded URL to grab the image file, and display it on the screen.
Included in the APRS MM database will be details on how to render the maps.
For example, for APRSdos map I have a program called dosmap.pl which
renders a map according to the parameters provided, writes the file to the
location indicated as one of the parameters, and returns the geo file to
STDOUT. The APRSworld maps would be rendered through an http request to
Jim's server. NWS radar maps would simply serve the geo files already
available.
Additional modules will be written for other kinds of APRS maps. Note that
although the APRS MM code and data will be GPL, there is no requirement
that these modules be released under any particular license. I would very
much like to see others develop and release such modules under the GPL, as
I will do with anything I develop for this project. I really, really want
to have help on this...I'm prepared to do it all on my own if I must, but
particularly in the rendering of other maps the help of others could get
this up and running much sooner, and provide access to a wider range of
maps.
I'm working on a protype system now, and hope in a week or two to be able
to demonstrate these concepts in practice, as well as releasing some
details about the design of the underlying database. Stay tuned for
details, and anyone that wants to help, please let me know. If there is
interest we can create the SourceForge project now, a person has stepped
forward to set that up.
Comments encouraged...
Steve K4HG
----------------------------------------------------------------------
Subject: RE: APRS MapManager
From: "Mark A. Lewis" <mark@siliconjunkie.net>
Date: Sun, 8 Feb 2004 11:41:04 -0600
X-Message-Number: 9
The one concern that I had reading this is the amount of traffic/load
that could be generated by this. If each time a person starts their
favorite APRS app or zooms, it makes a connection to the server to fetch
maps this could generate a huge amount of load. It would also be a real
hindrance to those with dialup internet.
This is all considering that I am understanding the proposal correctly.
----------------------------------------------------------------------
Subject: RE: APRS MapManager
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Sun, 8 Feb 2004 12:47:52 -0500
X-Message-Number: 10
Would it not allow users to download the maps at any time... to be able
to use them even if they are not connected to the APRS IS? Though there
may be lots of BW used for those who are APRS IS concentric... I see a
real benefit by having a central server to go to for maps of
preference... for use while mobile...
Maybe I misunderstand...
ALOHA
AH6LS
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
