How does MapServer store vector data internaly?

[Frank Warmerdam]

Tom Kazimiers wrote:
> Hello,
> 
> can you tell me how the MapServer deals with vector data? I mean what 
> happens after a Request?
> E.g.: If file not already open, the file is opened, a quadtree is build 
> and the request is performed on the quadtree data and no further file 
> reading is required.

Tom,

This is a very broad question.  The definition of what MapServer does is in
the source.  But I'll try to give a wee bit of information.  I'll address
this in the context of a WMS GetMap request with vector layers from shapefiles.

1) The map file to be used is identified, and parse into a mapObj.

2) The request parameters are parsed and used to manipulate the mapObj state.
    (turning layers on/off, setting the region and resolution, etc)

3) Each "on" layer is rendered in turn in msDrawLayer().

4) For vector layers, the layer is "opened" which basically means the
associated data files are opened.  In normal use vector file handles are
not kept open from request to request (since each request is a new cgi
invocation) and not even from layer to layer in the same map draw.  So
called "connection caching" in a fastcgi situation is an exception to the
rule.  For shapefiles this open results in opening the .shp, .shx, .dbf
and .qix if there is one.

5) The draw function loops through asking for shapes from the shapefile
code.  If there is a .qix file, mapserver will use it and the spatial
extent to figure out the shape indices to load. (actually, I think it may
do this in one complete pass and then sort the indices rather than doing
it on an ongoing basis).

6) each shape is drawn.  Note that the in-memory representation (a shapeObj)
normally only lives long enough to be drawn and is freed before the next
features is read.

7) the layer is closed, and all associated files are closed.

NOTE: there is no in-memory quadtree built.  If a qix (spatial index using
quadtrees) exists on disk it is used, otherwise all features are scanned and
compared to the spatial and attribute filters.  I think there is some short
circuiting of the shape reading to first look at the shape extent before
processing the rest of the shape.

Particulars vary based on the file type, the kind of request made, and
various other circumstances.  I'm also likely a bit off on some low level
details.  But hopefully this is a helpful response to what I claim is a vague
question!

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org