On Tue, Apr 14, 2009 at 11:39:02PM -0500, we recorded a bogon-computron collision of the <[email protected]> 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 <[email protected]> > > 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 _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
