[Xastir] slimming down dbf files

[Kyle Kienapfel]

It's always hard to get enough information across that I make sense,
but not so much that I spend a long time writing a large encyclopedic
article.

Heres the dbfawk that I used.
dbfinfo="NATRDCLASS:RTNUMBER1:RTNUMBER2:RTNUMBER3:RTNUMBER4:RTENAME1EN:RTENAME2E
N:EXITNBR:NBRLANES:PAVSTATUS:STRUCTID:STRUCTTYPE:STRUNAMEEN:ROADSEGID";
dbffields="NATRDCLASS"}

BEGIN_RECORD {key=""; lanes=1; color=11; name=""; filled=0; pattern=0; display_l
evel=8192; label_level=32; label_color=8; font_size=2; symbol=""}

/^NATRDCLASS=Local/ { color=0; }

I based my comparison on richmond, as it has a grid of busy roads, and
within is usually Local/<Something>.

So before I deleted ROADSEGID the roads are colored correctly, but
after I deleted the field, the roads aren't colored correctly.

Ah, deleting the field a second time, it works fine. Maybe the app
resorted when I wasn't looking.

I think the quadtree split I'm looking for is in shp2tile, but I'll
try that later


On 10/6/06, Tom Russo <russo at bogodyn.org> wrote:
> On Fri, Oct 06, 2006 at 01:30:38PM -0700, we recorded a bogon-computron collision of the <doctor.whom at gmail.com> flavor, containing:
> > I checked and the Geobase.ca NRN uses the ROADSEGID to associate which
> > shape with what dbf entry.
>
> This doesn't quite make sense.
>
> Per the shapefile spec there is *always* a one-to-one connection between
> records in the .shp/shx file (the actual geometry) and the DBF file (the
> attributes).  There is, for example, no value of "ROADSEGID" stored in the
> .shp/shx files to relate to the corresponding record of the DBF file.  Instead,
> the first shape in the file is always associated with the first record of the
> DBF file, the second shape with the second DBF record, etc.  It doesn't
> matter what attributes are stored or what columns are there.
>
> The geobase.ca folks might give each shape a unique ROADSEGID for their
> use, but that is not related to how the shapes are connected to their
> attributes in the shapefile spec.  It might mean that they use the ROADSEGID
> as a key to connect to other databases or other tables, but is not used by
> xastir (or any other program that manipulates raw shapefiles) to figure out
> what shape goes with what dbf record.  You should be able to throw away
> the ROADSEGID field while trimming your dbf file if you have no specific
> use for its value.
>
> > If theres no connection, xastir colors the
> > roads seemingly randomly (due to misassociation of the dbf entries).
>
> xastir will color records entirely based on how you tell it to, which
> you do by telling it how to decode attributes.  If your dbfawk file is
> causing "seemingly random" coloring, it's because your rules aren't catching
> things the way you expect them to, not because the DBF entries are being
> mis-assocated with shapes.  You just have to get your dbfawk rules to pick out
> the fields you actually care about and set your colors accordingly.
>
> My guess is that you're going to want to color based on the NATRDCLASS field,
> which I would guess (without looking at the metadata) encodes the various
> types of roads (highway, local street, etc.), with possible modifications
> based on PAVSTATUS and NBRLANES.
>
> >
> > This is whats left
> > dbfinfo="NATRDCLASS:RTNUMBER1:RTNUMBER2:RTNUMBER3:RTNUMBER4:RTENAME1EN:RTENAME2E
> > N:EXITNBR:NBRLANES:PAVSTATUS:STRUCTID:STRUCTTYPE:STRUNAMEEN:ROADSEGID";
> >
> > On 10/5/06, Curt, WE7U <archer at eskimo.com> wrote:
> > >On Thu, 5 Oct 2006, Jason Winningham wrote:
> > >
> > >> My (limited) understanding of dbfawks leads me to think we can
> > >> eliminate all the fields that are not listed in dbffields, adjust
> > >> dbfinfo accordingly, and we'll have a smaller file.
> > >
> > >I believe that to be correct.
>
> dbfinfo is used to check that the DBF file you give matches the "signature"
> of the dbfawk file --- the fields in dbfinfo have to match exactly the
> entire list of all fields in the DBF file.
>
> dbffields is used by dbfawk to pick specific fields out of the file for use
> in matching rules.  If you are only using the shapefiles for display in xastir
> (as opposed to other GIS uses) you can certainly trim out all fields from the
> DBF file that are not being used in rules and listed in dbffields.  The only
> reason not to trim them in this way is if you are using shapefiles for other
> purposes and need that extra data.
>
> --
> 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
>