Comments inline:
Javier de la Torre wrote:
Hi Brent,
You can have several different layers of the same data, and perform on the client side which to query. It shouldn't be very difficult to do that based on the zoom value you have on the client side.
But, how can I define different layers on the same data? You mean creating different Data types based on the same database table and apply different rules in the SLD document by default? So, for example, in my table I will have a column called zoom_level to indicate that this record should only be shown in this zoom level, then I create a featuretype called my_layer_at_zoom12 and create an SLD document for it that filter based on the zoom_level property.
Am I right with this?
If so I still have the problem that because filters in SLD documents are post-processed then to generate an image geoserver will retrieve all features from the database.
Other possibility could be to use views in PostgreSQL using this zoom_level and configuring feature types based on them, no?
What I mean is, you can create several copies of your data, say 3 or 4, and generalize them into smaller, simpler, datasets. So your most zoomed in dataset is the origional, complex dataset (in its own table), and the most zoomed out dataset is the simplest one with the least amount of data.
When your client script makes a getMap request, it can look at how zoomed in you are, and request the different datasets (FeatureType): the simplest one for zoomed out, and the original dataset for when it is zoomed in. So in the end you will have several FeatureTypes of the data, some simpler than the others.
The scale element in SLD is really only useful for filtering before rendering, so things look nice; it is not useful for filtering data in the query.
To create the different datasets from the one dataset, you will need a tool such as FME. There are other tools out there that are free, but I cna't remember the names off the top of my head.
Filtering your data on your 'zoom level' column is a good idea, but unfortunately it will be done after all the data has been selected in the query. Using views is a solution for this problem.
We have definitely created data sets with several million entries and tested it with GeoServer. Everything is great when using WFS, but WMS you have to handle more of it on the client side and request generalized layers when zoomed out.
I see, but if you go the WFS way when presenting large datasets you have to create pretty robust clients that can handle a lot of features and draw them. And also you have the annoying problem that you don´t know if you are getting all features for your query or is just the limit that the user set in geoserver. And if you want to retrieve 10.000 features and the user limit them to 1.000 there is no way you will be able to get the other 9.000 no?
That´s why I thought that WMS was a better way to handle large datasets, all drawing is done in the server and only when the user click somewhere uses WFS to retrieve info about specific features.
It is better to do the rendering on the server side with WMS, so the data passed to the client is minimal. And so you don't have to write your own renderer.
If you are worred about your users modifying the number of features returned, just don't let them specify the number. You can always set the max_features_returned value to be larger than your dataset and will get every row returned, if that is what was selected in the query.
Javier.
Brent Owens
(The Open Planning Project)
