Dear Christian Mueller and Geoserver/Geotools Community
I read the document related to the feature-pregeneralized geoserver extension and I think there are a confusion between what you are trying to do and what generalization applied to geographic data means (http://docs.codehaus.org/display/GEOTDOC/Feature-Pregeneralized).
At first I think the idea of having a method that improve data display is something desirable. I suppose you are looking for a solution for vector data like pyramid layers are for rasters.
If the aim of this module is only display improvement I suggest to move generalized information out of the geographic data base because if you put new child generalizated data as new geometries or shapefiles you can contaminate your database with spurious data without really geographic meaning.
Why you are creating spurious data?. Geographic generalization is not a one way process, it involves the application of several algorithms and expert considerations. Geographic generalization involves not only data reduction but also changes in data representation, classification, morphology, changes produced by different aggregation criteria at different scales, etc. It is a very complex process and requires to much geographical, cartographic and expert analysis. Then the result produced by one way generalization process will be a kind of geometry that will not be a valid representation of the original object or in other cases the new geographic object we need for the new scale.
Let’s see what happened with streams. Rivers generalization can be done by line generalization by point reduction but also by selection based on river hierarchies or by expert criteria. This process is something you can’t resume in an additional geometry item type or GEOMETRY_DISTANCE analysis.
Let’s see what happened with a polygon layer. You can reduce information by point reduction but this technique has a limit. At certain scales the current categories (polygons) must be aggregated in broader categories ( this is a geographic/cartographic rule ). But also automatic polygon generalization is much more complicate than line generalization because you also have to take in account spatial constraints like “sharing borders have to be generalizated in the same way”. Again this process is something you can’t resume in the geometry item or GEOMETRY_DISTANCE analysis.
Conclusions
What I tried to demonstrate is the current generalization model is only useful for data display improvement. I suggest to move the “generalizated” features for rapid display out of the spatial database. This solution will help the system modularization and management because it separates SDB from an artifact created for rapid display. I also suggest to change the extension name for something like “rapid display system”, “display by point reduction at different zoom displays” or “display improvement by point reduction”. Feature-Pregeneralized name create confusion with real geographic/cartographic generalization process.
Geographic feature generalization is a more complex process that involve several digital methods and expert analysis and it will require a extension with different kind of architecture.
My best wishes
Gabriel Asato
Unidad Sensores Remotos y SIG
Servicio Geológico Minero Argentino
(SEGEMAR)
Av. Julio A. Roca 651 p 8 of 1
Cdad. Autónoma de Buenos Aires
ARGENTINA
tel 54-11-4349-3158/26
fax 54-11-4349-3287
Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/