error message

[Stephen Woodbridge]

John,

The typical way wo do this is to create separate tileindexes for each
layer. So you would have a tileindex for roads, another for water lines
and one for water polygons, etc. For tiger data this would me you would
create approximately 10+- tileindexes. Then in the mapfile specify the
TILEINDEX and leave the DATA statement out.

I would recommend doing the above ... but for those that like to inflict
pain on themselves ...

There is an option on tile4ms like --directory-only that leaves off the
final file name, it unfortunately does not combine the multiple
directory entries into a single entry which renders it useless, unless
you want to write a script to do that your self. Assuming you wrote the
script yourself, you could then have ONE tileindex that would reference
the extents of the county regardless of the data layers in it, and you
could then set up your mapfile layers like:

LAYER
   NAME "streets"
   TILEINDEX "my-county-tiles"
   DATA "roads"
   ...
END

This would cause path in the TILEINDEX to be concatenated with the DATA
name to get the path to the data files. In this configuration only the
<tile-path>/roads.shp will be looked at.

I think I would recommend using the multiple indexes as it will be
easier to build and maintain.

-Steve

John Bolster wrote:

> Thanks Steve,
>
> I have various layers of tiger/line data organized into one directory per
> county and I've been trying to make one tileindex for the whole thing. Based
> on what you're saying, do I need to run tile4ms separately on each different
> type of layer, so that I end up with a tileindex for the counties, one for
> the roads, one for the places, etc.?
>
> John
>
>
>>-----Original Message-----
>>From: Stephen Woodbridge [mailto:woodbri at swoodbridge.com]
>>Sent: Tuesday, September 21, 2004 10:22 AM
>>To: John Bolster
>>Cc: MAPSERVER-USERS at LISTS.UMN.EDU
>>Subject: Re: [UMN_MAPSERVER-USERS] error message
>>
>>
>>John,
>>
>>The way tileindexes work is the you group a bunch of files into a
>>virtual layer. All the files must have the same dbf columns defined in
>>them and defined in the same order. This is because mapserver reads the
>>attribute layout of the first file it opens and uses that as the
>>template for all files in the virtual layer.
>>
>>So if the first file had attribute columns [A, B, C] and some other file
>>had [D, E] or [B, C, A] or whatever it would cause problems for
>>mapserver. If you ask mapserver to CLASS on C, it translates that to
>>column 3 and then tries to read column 3 from the [D, E] and gets an
>>error, or gets column A from [B, C, A] file, etc. This was causing a lot
>>of problems for people that did not understand the inner workings of
>>mapserver, so this check was added to prevent people from doing bad
>>things and not knowing about it.
>>
>>Some version of dbfdump will display the column definitions of you
>>files. You either have some that have a different definition like a
>>different version of the file, or you are picking up some files that are
>>not compatible with the first file you add to the index.
>>
>>Hope this helps,
>>   -Steve W.
>>
>>John Bolster wrote:
>>
>>
>>>Hello,
>>>
>>>Does anyone know what "DBF fields do not match" means in the output from
>>>tile4ms?
>>>
>>>Do they not match to one another, or to a certain way they're
>>
>>meant to be,
>>
>>>or to the shapefile, or what? The files were created with
>>
>>tgr2shp so I don't
>>
>>>see why they should be bad. And what would I do about this--I
>>
>>can't imagine
>>
>>>I'm the only person to whom this has happened.
>>>
>>>Thanks for your help,
>>>John Bolster
>>>
>>
>>
>
>