[Xastir-dev] national highway planning network dbfawk

Alan Crosswell alan at columbia.edu
Wed Oct 6 15:48:34 EDT 2004


I found many features in Tiger/Line DBF files that are miscoded (e.g. minor road 
segments categorized as major highways).
/a

russo at bogodyn.org wrote:
> On 6 Oct, 2004 Derrick J. Brashear wrote:
> 
> 
>>as a first pass i spent a few minutes on a dbfawk file for the highway
>>layer. but... i'm seeing fonts larger than i expect creeping in somehow,
>>and fonts not consistent with the road sizes that get drawn. am i screwing
>>up somewhere obvious?
> 
> 
> It's certainly not obvious.  It looks like you're assigning a font
> size based on feature type every time you assign a line width, and so if
> a feature has an FCLASS that matches one that you're testing for, it *should*
> get both the line width and font size you chose for that FCLASS.  
> 
> In some cases, you might be seeing instances of the data in the dbf
> file not actually matching reality --- GIS data can sometimes be
> wrong, and roads mismarked as major in the file attribute when they're
> actually dirt tracks.  Tiger/Line is like that in my area --- there
> are a number of insignificant cul-de-sacs that seem to have attributes
> in the census data that say they're highways.  But if, for example,
> you're seeing big fonts and really skinny lines, it's not coming from
> a mistake in your dbfawk file.  Could be a bogon in the drawing routines.
> 
> Have you looked with testawk to see how your dbfawk file is features
> into the dbfawk variables in reality?  dbfawk has evolved somewhat
> from what it was when testawk was written, and some dbfawk variables
> aren't output by it, but yours should be.
> 
> BTW, the final "font_size=0" shouldn't be necessary, as you have that
> in the "BEGIN_RECORD" section and that'll make sure that any feature
> not caught by your patterns get the default 0 font size.
> 



More information about the Xastir-dev mailing list