[Xastir] No DBFAWK signature for ...

[Tom Russo]

On Tue, Sep 06, 2011 at 01:06:09PM -0600, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
> On Tue, Sep 06, 2011 at 02:53:44PM -0400, we recorded a bogon-computron collision of the <huston at srhuston.net> flavor, containing:
> > On 9/6/11 12:27 PM, Tom Russo wrote:
> > > the nwsz_ddmmyy10b.dbfawk is the one that's closest to what you have, but
> > > honestly, the only difference between them is pretty much in that dbfinfo
> > > line.  So long as they continue to have fields that are called STATE_ZONE
> > > and NAME, that line is all you need to change to fix the problem.
> > 
> > For the record, I did both files:
> > 
> > $ grep ^dbfinfo nwsmzddmmyy_11.dbfawk
> > dbfinfo="ID:WFO:GL_WFO:LON:LAT:NAME:AJOIN0:AJOIN1";
> > $ grep ^dbfinfo nwsz_ddmmyy_11.dbfawk
> > dbfinfo="OBJECTID:STATE:CWA:TIME_ZONE:FE_AREA:ZONE:NAME:STATE_ZONE:LON:LAT:SHORTNAME:Shape_Leng:Shape_Area";
> > 
> > This cleared up all the errors I was seeing.
> 
> I figured it might.
> 
> I'll try to commit a new version into CVS tonight unless Curt gets to it 
> before me.

Committed.

Turns out that Gerald Stueve had already committed an nwsmzddmmyy_11.dbfawk
with the current signature back in May, but after the 2.0.0 release.

In order to get the latest dbfawks for the latest NWS shape files before the
2.0.2 release, you'll need to use CVS versions.  All the cool kids are doing
that, 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
 "One man alone can be pretty dumb sometimes, but for real bona fide
 stupidity, there ain't nothin' can beat teamwork." - Edward Abbey