On Wed, Apr 15, 2009 at 09:07:58AM -0600, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > > 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.
Just followed my own advice and ran map_shp.c through unifdef: unifdef -DWITH_DBFAWK map_shp.c > map_shp_onlydbfawk.c and see that the "quad_overlay" stuff is sadly *not* ifdef'd out by WITH_DBFAWK, so it is confusing. It is the case, however, that the only part of the code that ever sets "quad_overlay_flag" to anything other than zero *is* ifdef'd, rendering that code completely dead when dbfawk is enabled. Like I said, map_shp.c is a big mess because it contains two completely orthogonal sets of code. The old code for 24kgrid actually read the position of the label from the map itself. The dbfawk-enabled code doesn't do that. One *could* modify the dbfawk language and dbfawk code so that it supported that capability (for those few polygon shapefiles that have "label point" fields), but the payoff would probably be small (because few polygon shapefiles have label point coordinates in their attributes, and most would have to use the center of the bounding box anyway). -- 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
