[Xastir] strangeness drawing GNIS maps?

[Tom Russo]

On Wed, Jan 19, 2005 at 11:34:57PM -0700, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
> On Wed, Jan 19, 2005 at 08:48:12PM -0800, we recorded a bogon-computron collision of the <archer at eskimo.com> flavor, containing:
> > On Wed, 19 Jan 2005, Jason Winningham wrote:
> > 
> > > I noticed that, even when viewing a very small area (zoom 16) xastir will
> > > "draw" several states worth of GNIS data every time.
> > 
> > > Even though I'm zoomed in on a very small area in Alabama, it seems to draw
> > > maps for AK, IL, IN, TN, etc etc.  The map is actually drawn correctly, the
> > > problem is the CPU time involved in not drawing all those maps.
> > > 
> > > Maybe there's a problem with the data?
> > > 
> > > What are the values in map_index.sys?
> > 
> > The important values for this discussion are the
> > top/bottom/left/right edges of the map data.  Those extents get
> > stored into the map_index.sys file.  If you have some errant values
> > in there, Xastir will think the map might cover the area in question
> > and run through the map attempting to find them.
> > 
> > You might try reindexing those maps to see if that helps.  Perhaps
> > you got some bad extents in there.  The extents are in the Xastir
> > coordinate system:  Units of 1/100's of a second, lat/long.  Origin
> > is at upper left and numbers proceed in a positive direction east
> > and south.  You can look at some of the comment blocks in maps.c to
> > find out how that coordinate system works.  It's what I do each
> > time.  Line 448 is a good place to look.
> 
> I'm looking at this now --- I believe the problem might lie in the gnis
> files, where some lines appear to have no lat/lon value.  It's not immediately
> clear that the code actually handles this gracefully, and perhaps it's 
> mussing up the index.  
> 
> When I look at my index file, containing NM, IN, AL, AZ, TX, and WA gnis
> entries, it's showing the first number (which I think is supposed
> to be the bottom extent) of AL, AZ, NM, TX and WA to be the same, and IN
> nearly the same  (0032400000, the equivalent of the equator in xastir
> coordinates).  Each of these files has at least one line with no lat/long 
> values --- which leads me to believe that the lines with blank lat/lon
> fields are interpreted as 0 latitude.  This would cause broken bounding boxes
> and make it seem as if the file should always be drawn.

Yup, the "UNKNOWN" fields of the gnis files were being parsed as lat/long.
I have a patch and will commit it shortly.  It improves matters and creates
bounding boxes that really do consist of the min/max of the lat/lon points
in the gnis file now.

Unfortunately, I noticed that in the case of Texas and Alabama, the GNIS files
have one odd line each with points far outside the state borders.  In the 
case of Texas, it's the Intracoastal waterway at 25.8N, 80.1W.  This means that
the TX GNIS file wants to get loaded even if you're zoomed in on Florida.
Alabama has a similar intracoastal waterway line, pointing at 25.815N, 80.176W.
Short of editing out these outliers from the gnis file, there's nothing
to be done about that.

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 
 "When life gives you lemons, find someone with a paper cut."