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
