[Xastir] dbfawk & fills

Tom Russo russo at bogodyn.org
Fri Dec 14 01:32:34 EST 2007


On Thu, Dec 13, 2007 at 10:14:18PM -0500, we recorded a bogon-computron collision of the <n1mie at mac.com> flavor, containing:
> 
> 2. I was noticing some stuff that didn't seem to respond to the adjustments 
> I made. Some seemed to be streets, some were other features. I looked in 
> one of the county shape files and noticed a few very odd items. There were 
> some with numbers like P41 in stead of A41 (these were streets). I added a 
> line to handle the P4's and that fixed part of the problem, but there are 
> still more. 

According to the TIGER/Line documentation, Feature Class P is for "Provisional" 
features:

  "The U.S. Census Bureau has created a new CFCC type that may appear on
   street features only.  Some streets that normally would be classified as
   "A" class features may be coded with a "P" instead of the "A" to indicate
   that the feature is a a "provisional" feature.  Provisional features are
   those streets that were added from reference sources or other programs
   in preparation for Census 2000, but were not field verified by census staff
   during field operations or through the use of aerial photography or imagery.
   As these featues are verified in futuer operations the provisional flag
   will be removed for subsequent TIGER/Line releases.  The numeric portion
   of the CFCC still classifies the street as if an "A" were preceding it."

So the thing to do is to look in tgr2shp.dbfawk and change all the lines like:
  /^CFCC=A1/ {lanes=4; color=4; label_level=512; font_size=3; next}
to read
  /^CFCC=[AP]1/ {lanes=4; color=4; label_level=512; font_size=3; next}

When Alan Crosswell originally made the "tgrlk.dbfawk" file to deal with the
ESRI versions of the Tiger shapefiles (from which I based tgr2shp) there
was no such "P" feature class, and when I migrated a lot of his work into
tgr2shp I added a few feature types but I didn't pour over the entire 300 page
TIGER/Line technical documentation to find them all.  That explains
why it's not there yet.

I was able to do this fix trivially and just committed it to CVS.

>  I suppose I should develop a script or something to identify all 
> those that don't fit the known mold. But I thought I'd inquire here before 
> I duplicate any effort.

If you find any others I'd be glad to look for them in the TIGER/Line 
documentation to see what they're supposed to be.  Or you can go to the Census
site and download the PDF documentation for the files yourself and find feature
codes in there that Alan and I overlooked or didn't bother with.

> 3. So now I've got the dbfawk file just the way I want it. But I notice 
> that it's in the system-wide ../share/xastir/config directory. It appears 
> to me that the files in that directory will be overwritten when Xastir is 
> re-built. 

Yes, indeedie.  That's exactly what will happen.

> Is there a place (like ~/.xastir/config) where they can be placed 
> and read (aside from putting them alongside the maps) where they won't be 
> over written?

No, the only two options are the config directory (in which case they're used
for signature-based matching) or along side the maps (in which case they're
matched based on file name, and there would have to be one for each file (or 
a mess of symlinks)).  And you while there's nothing preventing you from 
having two files in the config directory with the same signature, I'm  not
sure how the dbfawk code would choose between them when deciding what to use --
it is likely that it would use the first matching signature it finds in its
internal data structure, but I don't know if that means the first one it finds
in the directory or the last one it finds.

If you have suggestions for how to improve the tgr2shp file I'm willing to 
commit changes like that into the one in the repository if they look good, then
you won't have to deal with that issue.  Or you can just save your version
and copy it back into config every time you update xastir (bleah).  Or you
can do your modification in your Xastir source directory so that when you 
CVS update your changes are preserved (and merged together with any other 
changes we do).   But you're SOL there if you just use tarballs instead of
CVS (but why would you do that?).

> 4. How do I get state lines? I don't see those appearing anywhere in the 
> files. I didn't see them as a separate file and they don't seem to be in 
> the one dbfawk that I got to work editing (tgr2shp.dbfawk).

That data isn't in the TIGER/Line files, which are county-based, so you can't
get state lines out of them.  If you want state borders, use a different 
shapefile such as the "statesp020" shapefile from the National Atlas.  There's 
a dbfawk file you can use on my http://www.swcp.com/~russo/shape_web/ site.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick



More information about the Xastir mailing list