[postgis-users] "Summarizing" a collection of geometries

[Kevin Neufeld]

Hi Reid,

I'm not sure I fully understand your use case, but you may be able to 
make use of PostgreSQL's schemas and duplicate your source data in 
several schemas, where each schema represents a simplification of your 
dataset.

For example,
You could have a one schema, call it zoom_level_1, for storing the 
tables of your original dataset.

Then create a second schema, zoom_level_2, for storing the same tables 
as the 1st, but the geometries have been simplified. 
- point tables could be snapped to a grid in an attempt to make things 
less dense (ie. 1 meter)
- linear tables could have short line segment dropped, and longer 
segments could have simplify() run over them at some tolerance,
- polygonal tables could have small polygonal holes removed, and then 
simplified.

Then create a third schema, zoom_level_3, for storing the same as the 
2nd, but further simplified
- points are snapped to a more course grid, (ie. 1 km)
- you might want to only keep the endpoints of longer linear features, 
or run simplify() using a more course tolerance.
- small polygons could be converted into points, drop all holes

etc....

Then you client app / web app / or whatever can simply use the schema 
appropriate to their zoom level since none of the table names have changed.

I've done this before with large datasets, (16 million features), 
creating 10 or 12 zoom levels ... makes for an effective and quick WMS 
viewer of your dataset.

Cheers,
Kevin

Reid Priedhorsky wrote:
> Dear list,
>
> I would like to compute a "summary" of a collection of geometries 
> (points, linestrings, polygons, or any combination).
>
> Here is the use case. I would like to summarize the geometry 
> collection and present this summary visually so users working at a 
> small scale can see, "ah, if I zoom in here, I can see more details 
> about this geometry collection".
>
> The simple solution would be to compute a convex hull or bounding box, 
> but this fails if the members of the collection are far apart (users 
> could zoom into the middle and see nothing). In this case the summary 
> would need to be a multipolygon. But the trick is figuring out when to 
> split summary polygons into multipolygons.
>
> Has this been done? Do any of you have suggestions or references?
>
> It is very preferable to do this entirely in the database rather than 
> in external code. Embedded procedures are fine.
>
> As you can see I am not entirely sure of my terminology, so any 
> suggestions there would be welcome as well.
>
> Many thanks,
>
> Reid
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users