This talk is about practical methods for managing performance and interactivity in geometry-based systems.
You may have worked with a great spatial application that was handicapped or taken out by one nasty layer, or even one pathological feature. Or maybe you over-specified an application server because you weren't comfortable estimating what capacity would be needed.
These things happen because geometry data presents certain specialised problems. Geometry records vary in size. Common operations on geometry are complex. And in a way that's hard to predict, the spatial relations described by geometry bring a varying number of these variably complex records into play.
Big ideas in GIS history take aim at this lumpy and uneven source data: the spatial index and the map render cache are two famous examples. But even when we use these ideas to make our interactions with geometry more predictable, we still face anxiety about tricky cases—the coastline feature with hundreds of thousands of vertices, the mining exploration proposal with a hundred thousand surveyed drilling points, or the State cadastre.
In GIS we usually don't do a great job of measuring and controlling our geometry, and we are lazy designing for complexity. But with a more proactive approach to data management, and an improved understanding of particular spatial operations, we can all learn to love the_geom!