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 <[EMAIL PROTECTED]> wrote:
On Fri, Oct 06, 2006 at 01:30:38PM -0700, we recorded a bogon-computron collision of
the <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
_______________________________________________
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
