[Xastir] APRSPoint discussion from APRS sig

J. Lance Cotton josecanuc at gmail.com
Fri Dec 3 16:44:45 EST 2004


On Fri, 3 Dec 2004 15:28:04 -0500 (EST), William McKeehan
<mckeehan at mckeehan.homeip.net> wrote:
> On the APRS sig, there was some discussion about APRSPoint vs Xastir.
> 
> I thought I would toss my comments about using other mapping software into
> this group to get your feedback.
> 
> 1. Fast map scrolling.
> The biggest improvement that I would like to see in Xastir is faster map
> scrolling/changing. I suspect that the reason it is currently as slow as it is
> is because of the large number of map formats supported (one of Xastir's
> greatest features). One way that I can imagine increasing the speed would be
> to convert all maps to a single format. Is this on one of the developer's idea
> list? Maybe not all map types would be able to fit into this format, but it's
> a thought worth exploring.

The slowness doesn't come from the variety of supported maps, but
because Xastir re-renders the view window each time a scroll or zoom
occurs. This means that it has to re-parse the shapefiles, reload the
raster maps, etc.

Some work has been submitted recently which allows xastir to cache the
Internet-based TIGER maps (raster), which is a big help for those who
use that format.

In my opinion, the most powerful/useful map format is some kind of
vector format, like Shapefile. It would be great if we had a highly
optimized renderer of shapefiles, but we don't. Things sped up by the
fact that xastir will skip over processing a whole shapefile or
(within a shapefile) a segment that is not in the draw window.
However, Xastir still iterates through EVERY element in a shapefile,
regardless of whether it jumps to the draw routine or not.

I think this is an opportunity for a huge performance increase. If we
could either optimize the processing of shapefiles (Curt has already
done so much in that area compared to a year ago!) or find a library
which is highly optimized for rendering shapefile maps, then we could
eliminate much of the "slow" map drawing.

For instance, instead of iterating through the segments, some kind if
database-like access would allow xastir to request only those segments
bounded by some rectangle and then let the highly-optimized
sub-function to return only that. Don't get me wrong, though, I don't
want to see SQL access to shapefile segments... That just doesn't seem
right.

Maybe we could look at other opensource programs that use shapefiles
to see what kind of methods they use for fast rendering of the maps?

-- 
J. Lance Cotton, KJ5O
joe at lightnigflash.net
http://kj5o.lightningflash.net
Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3.
Eat the cookies.



More information about the Xastir mailing list