Dear Chris
I am Geoserver fan. The only thing I wanted to do by raising this problem to the community is to give some feedback about what I considered a conceptual misunderstanding of generalization process and help to improve what you are calling pre-generalization features. I know very well this is a discussion forum and this is what I pretended: to open a discussion and share knowledge and experiences not any other thing. I have to confess I do not know so much about FOSS4G etiquette and you were very polite telling me how I have to demonstrate and present my arguments.
About generalization process what I wanted to demonstrated in the last mail is a conceptual problem not a code problem for that reason I am giving you some bibliography links about generalization were you can check some of my arguments (Geographic feature generalization is a more complex process that involve several digital methods and expert analysis …, Sorry but this last phrase was the best I could do trying to simplify all the know how that follows).
Good brief introduction to definitions and problems
http://en.wikipedia.org/wiki/Cartographic_generalization
An old but complete paper about cartographic generalization
http://www.survey.ntua.gr/main/courses/geoinfo/admcarto/lecture_notes/generalisation/bibliography/mcmaster_shea_1992.pdf
This is a new one. I haven’t completely read it but it looks nice. It give a good description of generalization operators and constraints.
http://www.kartografie.nl/kobben/publications/ICC07_foerster_stoter_kobben.pdf
Good book introduction that explain some limitations of sdb generalization (model) vs cartographic generalization (graphic) and give a broad idea of the state of generalization art.
http://www.colorado.edu/geography/babs/shape%20bibliography/Computational%20perspectives%20on%20map%20generalization.pdf
Importance of cartographer know how in the generalization process and a proposal architecture for a expert generalization system
http://www.gmat.unsw.edu.au/snap/publications/kazemi_etal2005b.pdf
Good introduction to generalization and web mapping. This is something of your particular interest.
http://www.geo.unizh.ch/publications/acecconi/phd/pdf/chapters/chapter2.pdf
This last article also briefly explain some structural limitations about GIS as a platform for cartographic generalization.
This is a very old but comprehensive paper, I am not sure if is possible to find out it now in internet.
ESRI, 1996 . “Automation of Map Generalization. The Cutting Edge Technology”. Esri White Papers Series. May 1996.
There are another interesting work about generalization made by International Cartographic Association but unfortunately I haven’t found it. I hope not forget any useful generalization paper.
In those easily finding articles you can see that generalization process involves a several well know methods like:
-Simplification
-Generalization by selection
-Anamorphosis or displacement
-Typification
-Generalization by classification
-Aggregation
-Symbolization
-Exaggeration
Unfortunately there are not an automatic process that can deal with all generalization problems in one way (sorry but I hope at this time you can now understand why I can not give you a complex generalization code, nobody in earth can ). You need a combination of them, you need to select a special algorithm from a list that belongs to one of the last enlisted methods (line simplification can be done by more than one algorithm and same is with others) and at last a cartographer or geographer have to check the result and decide what methods did not the work well and try to make some modifications by hand (yes you read very well by hand 
, for more references about hand see http//ica.ign.fr/Leicester/paper/Hardy-v2-ICAWorkshop.pdf, http://www.gmat.unsw.edu.au/snap/publications/kazemi_etal2005b.pdf, C.G.Asato.An Example of Consistent Spatial and Thematic Data Integration in large Areas by GIS: the Geological Map of Santa Cruz Province (Argentina). In: GIS and Spatial Analysis-Proceedings of IAMG’05 ,[C].2005, Toronto, Canada).
In the other hand generalization process have several constraints. According the International Cartography Association generalization process, in theory, can be made until 6x data reduction. According to one paper I published with current technology is only possible to make a 3x scale reduction for complex maps like geological maps ( generalization became more difficult in thematic and choroplet maps more generalization constraints araise, C.G.Asato.An Example of Consistent Spatial and Thematic Data Integration in large Areas by GIS: the Geological Map of Santa Cruz Province (Argentina). In: GIS and Spatial Analysis-Proceedings of IAMG’05 ,[C].2005, Toronto, Canada).
When I suggested (please noted I used the word suggested) to get out from your SDB the derived GEOMETRY_DISTANCE data I tried to explain that you are contaminated your database with spurious data. You are introducing data that cannot be processed by others ST SQL instruction in a consistent way because the data generated by the GEOMETRY_DISTANCE is rubbish in the geographic sense. This data only has a meaning for only one process. You are moving a display problem to your database, not to your application. You are introducing in your geographic feature a series of geometry items that not represent the original geographic object, a kind of spatial inconsistent information and of course it creates a potential source of analysis problems ( I am not discussing what the user want to do, I am discussing what the application is doing with the user database).
Please try to make the following experiment: take a complex stream layer, make different generalizations using GEOMETRY_DISTANCE from 1:250k to 1:1M and see what happened with shapes. If you also want to know much more about GEOMETRY_DISTANCE constraints (as I show you in the previous mail), please make the same experiment with a choroplet map (like a soil map) and see what happened with boundaries.
If you still want to keep the pre-generalized information in your SDB, please my suggestion is ( please noted I giving a solution ) put that program oriented information in a separate table from the original feature table where you good data stayed.
There are a lot of derived subjects that still remains and I seeing this mails is becoming larger and larger. Sorry for that but I felt you need a more deep explanation I originally supposed. BTW I will try to close at least one of the derived subjects and try to discuss next ( if you want ) how to use pre-generalizated extension in a what it is possible a more consistent way.
I think I illustrated the community about the generalization process problem is a complex process that can not be simplified in one code. Some of the automatic generalization problems still remains and belongs to different fields of research. In order to help and prove my position I gave some links to different papers.
In regards of the pre-generalized horizontal layout I suggested to move new geometries created with GEOMETRY_DISTANCE from the feature table to other table created specially for this application. Following this idea you can translate the display problem from the user SDB to the application database.
I hope this information will help your nice work.
My best regards
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
De: Chris Holmes cholmes@anonymised.com
Para: Carlos Gabriel Asato g_asato2000@anonymised.com
CC: geoserver-devel@lists.sourceforge.net
Enviado: mar, octubre 13, 2009 6:36:08 PM
Asunto: Re: [Geoserver-devel] Feature-Pregeneralized Extension observation
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.
Where do you propose it be moved to? A spatial database to me is just a great storage system, and this pre-generalized data has to be stored somewhere. It’s up to the user to determine what they’re using the store of information for. Many may choose to keep their core data in one database, and use the jdbc feature pregeneralized database just for display purposes.
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.
If you’d like to effect this change in the community the best way is to show up with code. If you create a module that actually does this more complex process that you speak of you could likely make a solid argument that it should be named feature pregeneralized, and that Christian’s module should be renamed. But if that’s not there I think the current name is decent, even if not perfect. ‘Rapid display system’ I don’t think is accurate enough, and the other two names you proposed are too long and verbose.
best regards,
Chris
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
ARGENTINAtel 54-11-4349-3158/26
fax 54-11-4349-3287
Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
– Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/