[Xastir] dbfawk & fills

[Chip Griffin]

First and foremost. Tom, thank you for the quick and detailed  
response. I noticed it was sent shortly after I sent the inquiry.

On Dec 14, 2007, at 01:32, Tom Russo wrote:

> According to the TIGER/Line documentation, Feature Class P is for  
> "Provisional" features:
>
> 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}

That makes sense. I know there is something else, but I haven't  
looked yet. I'll let you know what I find. It'll be easier when I  
figure out a GREP or similar solution to filter the known stuff.

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

Which I won't get until I resolve the item mentioned in #3 in the  
original message!

> 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.

Roger, will do.

>> 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.

Icky poo.

>> 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.

This sounds like an excellent place to put some manhours (easy for me  
to say since I lack the skills). I would love to see this resolved a  
little more elegantly. I would envision one of two methodologies.  
Either a deliberate scheme where one could put multiple redundant  
files in the same directory and predict which would be utilized  
(alphabetical or something along that line). Alternately (and  
preferably) would be something similar to how the xinitrc files work.  
The system defaults would be in the ../share/xastir/config directory  
and the user would put modified copies in the ~/.xastir/config  
directory (or similar location). This has a few benefits. (1) user  
changes are not lost in the upgrade process since presumably the  
~/.xastir/config directory is not overwritten then (2) each user on  
the computer can have their own version of the dbfawk files without  
fighting over it (3) it will be elegant and consistent.

Anyone willing to work with me to do some coding?  :)

> 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.

Thanks, I'll let you know.

> 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?).

I use CVS, but am still new enough at it to not have figured out how  
to block an update of an individual file or files. But I do learn  
fairly quickly.

> 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.

Aha. I'll go get those.


-- Chip