This is a proposal sent to the APRS SIG Feburary 8, 2004, describing my plans for dealing with the mapping issue. 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...