<gridding>
Model data sources (as defined by the <model> tag) allow you to incorporate non-terrain layers into a map. Some model drivers operate on "feature" or "vector" data, reading it and turning it into 3D geometry or an overlay. For data with very large numbers of features, or data that spans a wide area, this can lead to large models and inefficient rendering.
The gridding policy exists to mitigate this issue by providing the model driver some parameters for divvying the data up for more efficient rendering. How each model driver uses this information is implementation-dependent.
The built-in Model Feature drivers (like feature_stencil and feature_geom) honor this policy and divide the resulting geometry into cells.
Attributes
| cell_size | The maximum size (both width and height) or a grid cell. Specifiy this is source data units. | required |
| culling_technique | How to decide what data goes into which cell. Set to crop to crop geometry to fit in each cell. Set to centroid to place a geometry in a cell only if its centroid falls within that cell. | optional; default = centroid |
Example
Here we render a Model layer with road vectors in a UTM-meters projection. We set the grid size to 1000 (1 sqkm), and tell it to crop roads to cell boundaries. Finally we apply a style to render the roads 10m wide. (Note that values like the cell size, stroke-width, etc are specified in the same units as the source data .. in this case meters. If the source data were in degrees, you would specify these values in degrees.)
<model name="roads" driver="feature_stencil">
<features name="roads" driver="ogr">
<url>../data/roads-utm.shp</url>
</features>
<gridding cell_size="1000" culling_technique="crop"/>
<style type="text/css">
roads {
stroke: #ffff00;
stroke-width: 10;
}
</style>
</model>
