[Xastir] Town/Subdivision Names in shapefiles (static Tigermaps)

[Tom Russo]

On Tue, Apr 14, 2009 at 11:39:02PM -0500, we recorded a bogon-computron collision of the <kg5lt at verizon.net> flavor, containing:
> 
> On Apr 14, 2009, at 1:55 PM, Jason KG4WSV wrote (offlist):
> 
> > On Tue, Apr 14, 2009 at 1:12 PM, Dale Seaburg <kg5lt at verizon.net>  
> > wrote:
> >> I've been over the HowTo:DBFAWK, README.MAPS and 2008 TIGER/Line  
> >> Shapefiles
> >> docs - perhaps not thoroughly, though.  Has anyone else had  
> >> success with
> >> getting Town/City names to appear?
> >
> > Nope, we're all sitting around waiting for you to get all the work
> > done so we can start using the new shapefiles. (:
> >
> 
> 1.  The label font size needs to scale with the zoom level.  It's way  
> too big when you see multiple counties (Texas-sized counties which  
> are relatively small).

As Jason points out, there is no such capability in Xastir at this time.
The label font size is set once, and is used at all zoom levels.  To do
otherwise will require extensions to the DBFAWK language and the map 
rendering code.  This would be a good thing for someone to do.
The DBFAWK language could use some extending.  But it's not easy, and nobody
has the time or inclination.

> 2.  I was surprised to find that the rule line: /^MTFCC=G/ . . .  was  
> basically ignored.  The display level did nothing.  I dropped the  
> color without detriment.  I added font_size and several other fields  
> to no effect.

That's puzzling.  I can only guess that the records are not in fact matching
the way you think they should.  Are you sure that pattern is the right 
pattern?

> 3.  The position of the label is a mystery.  I think it has to do  
> with "quad" location, but not sure.  In some cases the label isn't  
> *even* close to the town.  This may have to do with the census data's  
> location values, too.

The "quad" location stuff is a red herring.  If you're running with DBFAWK
enabled, that code is ifdef'd out.  The only parts of map_shp.c that are
relevant when DBFAWK is enabled are those inside the #ifdef WITH_DBFAWK
sections.  Ignore code in the #else sections of those ifdefs.  There are
also some sections that have #ifndef WITH_DBFAWK, so you ignore the stuff 
in there and pay attention only to their associated #else sections.

map_shp.c is a big mess because we're allowing the user to build without
dbfawk (because dbfawk requires pcre, and the user might not want
to install it).  With dbfawk disabled, there's a whole bunch of code that
renders very specific hard coded shapefiles in detail.  With dbfawk enabled,
all that is tossed and everything is controlled by the dbfawk file.

Labels for polygons are placed roughly in the center of the bounding box for
the polygon.  Labels for lines are placed close to one end of the line and
oriented along the first line segment of that polyline.  Labels for points
are placed near the point.  Placement can be very ugly.

> With regards to #3, I saw in map_shp.c that the city label was near  
> the quad label code, and seemed to be a bit related. Sorry if I don't  
> know the in's and out's of that code.  Hard to follow when you don't  
> know the bigger picture how it fits together with other code along  
> with "where did that come from...".  It made enough sense to me to  
> realize that changes to the code were probably not the answer to  
> making the labels visible in the first place.  ;-)

The key to reading map_shp.c is to figure out how to ignore all the stuff
that's not compiled when dbfawk is enabled.  Judicious use of the "unifdef"
program can help to produce a version of the file that is more readable.

In fact, the quad and city label code is the non-dbfawk stuff that is 
irrelevant to your issue.  That code is there to render two different
specific shapefile sets --- the quad code is for the 24kgrid shapefile
from geocommunities, and the city code is there for the very, very old 
ESRI Tiger shapefile conversions that I doubt anyone uses anymore.

> Also, Craig, N6YXK said that he was having trouble with the secondary  
> road appearance not doing as he expected when zooming in/out.  I did  
> play a bit with the edge.dbfawk and the rule: "/^MTFCC=S12/ . . ."   
> Changing the "display_level" value did make my secondary roads change  
> size/color at different zoom levels.  That may help, Craig.

How puzzling.  You should not be able to change the size and color at different
zoom levels through dbfawk rules.  You can only turn shapes on or off based on 
zoom.  You can use "display_level" and "label_level" to define the lowest zoom 
level at which a shape (or its label) is displayed, but there shouldn't be any 
way that you can make the color or width change at varying levels.

One could construct an elaborate collection of copies (or symlinks) of 
maps with different per-file dbfawks and use the "min zoom" and "max zoom"
properties in the map properties dialog to get such an effect, but it would 
make God cry and probably kill a kitten or two.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
  In some cultures what I do would be considered normal. 
                                  -- Ineffective daily affirmation