[Xastir] Since we are talking about dbfawk...an issue

[Richard Polivka, N6NKO]

Tom,

I may not be flexible enough but I kicketh myself in the butt.

I had my original .dbfawk file in the config directory and when I put in 
the CVS version, pointlm.dbfawk was put in and the two were fighting.

I had the command syntax right but xastir must have been confused by 
seeing both and did whatever to display the cul-de-sacs.

Thanks again,

Richard, N6NKO


Tom Russo wrote:
> On Tue, Apr 21, 2009 at 09:49:50PM -0500, we recorded a bogon-computron collision of the <r.polivka at sbcglobal.net> flavor, containing:
>   
>> How do I go about ignoring the display of a particular feature?
>>
>> I don't want the "x" displayed at the end of cul-de-sac's (MTFCC code 
>> C3061).
>>
>> What is the structure of the line to accomplish this? I am getting nowhere.
>>     
>
> Two ways to do it:
>
> If the majority of features in the shapefile are features you want to display,
> set display_level to something reasonable in BEGIN_RECORD, and set it to 0
> for features you don't want.  So in pointlm.dbfawk, if most features are
> features you want displayed, leave display_level where it is in BEGIN_RECORD,
> and add a dbfawk rule:
>
> /MTFCC=C3061/ {display_level=0; next;}
>
> Make sure that no earlier rule matches such a record first.  For example, if
> you have 
> /MTFCC=C3/ {display_level=512; next;}
> (which you do), then you must put the C3061 rule earlier in the file so that
> only those MTFCC=C3... that aren't C3061 get caught by the less specific rule.
> Or modify MTFCC=C3 so it's more selective.  It is currently matching anything
> that has an MTFCC that begins with C3.
>
> Conversely, if the shapefile has mostly features you don't care about, set
> display_level=0 in BEGIN_RECORD, and explicitly set it to something else for
> each MTFCC code you *do* want displayed.
>
> Alternatively, use ogr2ogr to create a shapefile that doesn't even have those
> features in them.  This will speed things up tremendously if there are lots
> of features being skipped over in dbfawk processing.  The up-front effort is
> greater, but the payoff is faster map rendering.
>
>