Hi,
I want to try and keep posts to this list on Geoserver related problems, so, agree with your suggestion to manually set extents having weighed up the datasets geometry update frequency/significance. The dataset I encountered the problem on does not experience significant, regular updates to its geometry which would warrant regular updates to the extents GeoServer stores for it so your suggestion works a.ok in this case. When new data is added (most likely case), we re-optmise the DB tables affected and manually update the extents through the GeoServer FeatureType editor.
The real problem as Andrea, Justin and Brent identified is in the PostGIS function - extent() - GeoServer ( 1.5-RC1) uses when generating the WMS Capabilities document - oddly though not for WFS/WCS. For large datasets, of which we have a number including the one described above, this function is simply too slow as it does a complete table scan and this takes a significant amount of time and consequently holds up the time it takes to return the capabilities doc. Throwing more hardware resource at it is not an option, but giving the user the ability to opt to use the faster - estimated_extents() - function or previously generated extents, extracted or transformed from what’s stored in the FeatureTypes info.xml doc, would be better. Better, until such time as a more accurate, but equally fast method of extracting exact aggregate bounds from large PostgreSQL/PostGIS tables is available.
Like you say, each persons situtations and requirements are different and ours/Geoserver users is with;
- Geoserver’s use of the - extents() - function by default when generating FeatureType extents, when generating a WMS capabilities doc,
- the speed of the PostGIS - extents() - function when used with large tables,
- the innacuracy (~95%) of the alternative - estimated_extent() - function and the impact on spatial queries based on extents this function outputs.
I am usually playing with nationwide data and the extents of Finland have not changed since 1945 …
I agree with the approach suggested, but will add this; we also work with national and in some cases global datasets but we also have spatial datasets which cover smaller areas ( e.g. individual features, research project specific test areas, towns, cities, counties, regions), and involving varying ‘numbers of features’ from 1 to 20million+. The majority of these datasets are located within the UK national extents and could be assigned a blanket national (UK) extents but this has the side effect of limiting the result accuracy and usefulness when performing discovering ( i.e. spatially searching) across these datasets, also many WMS supporting clients use the extents as a key bit of configuration info, for doing things like, data lookup, applying geoprocess to multiple layers, zooming to extents, or pulling in other data that exists within the same extents.
A while back there was a brief thread discussion over here → http://lists.burri.to/pipermail/geowanking/2005-October/002017.html - which raised a few reponses on the subject of true/exact vs.intended extents.
Regards,
Simon
On 06/03/07, Rahkonen Jukka < Jukka.Rahkonen@anonymised.com> wrote:
Hi,
I am usually playing with nationwide data and the extents of Finland have not changed since 1945 and I hope they won’t in near future either. So I believe that at least in my case calculating the exact extents from the database does not give much extra value if only the extents are wide enough to hold all the data. Usually our data are not spread uniformly so there are in any case areas without data inside the bounding box. Your situation may not be the same.
Regards,
-Jukka-
Lähettäjä: Simon Abele [mailto: simon.abele@anonymised.com]
Lähetetty: ma 5.3.2007 21:56
Vastaanottaja: Rahkonen Jukka; geoserver-users@anonymised.comsts.sourceforge.net
Aihe: Re: [Geoserver-users] Geoserver 1.5-RC1 - SLD Filters + large datastore extent problems
Jukka,
Thanks for the suggestion. In the absence of an equivalent, explicit way of declaring the bbox of a featuretype in its default SRS in the way Mapserver’s ‘ows_extent’ MAP file element allows, I (or anyone else) can simply add the lat/lon (epsg:4326) extents (bounding box) within the featuretype editor. However, Geoserver is rightly (imho) recalculating FeatureType extents, post configuration to account for interim changes to the data ( e.g. inserts, updates, deletes) which might have the effect of changing the geometry and hence aggregate extents. This becomes a problem when applied to large FeatureTypes using PostGIS as the DataStore. The PostGIS functions to compute aggregate extents as Andrea and Justin point out are simply too inefficient (read, takes too long) - but unavoidable, until a better approach is put forward/implemented.
For the time being Andrea’s suggestion of making it possible for the user to opt in and tell Geoserver to use the less accurate, but faster estimated_extents() function for specific FeatureTypes seems a sensible solution.
Cheers
Simon Abele
GeoInformatics Research Group
School of Civil Engineering and Geosciences
Newcastle University
Newcastle upon Tyne, NE1 7RU, UK
web: http://www.ceg.ncl.ac.uk
On 05/03/07, Rahkonen Jukka < Jukka.Rahkonen@anonymised.com <mailto: Jukka.Rahkonen@anonymised.com> > wrote:
Lähettäjä: geoserver-users-bounces@lists.sourceforge.net puolesta: Simon Abele
Lähetetty: ma 5.3.2007 4:18
Vastaanottaja: geoserver-users@lists.sourceforge.net
Aihe: [Geoserver-users] Geoserver 1.5-RC1 - SLD Filters + large datastoreproblems
The query (which is a particularly enificient method to compute the the envelope (bbox)) takes ~3-5 min to >run and the more features a table contains the longer the query takes to execute. The problem - the wait for >the query to execute - is just about tolerable when configuring a FeatureType. However, the problem also >seems to affect (more so) the speed with which WMS GetCapabilities requests return, as the same query is >run, and run for each FeatureType!.
Hi,
I don’t know about Geoserver, but I do know that with UMN Mapserver this very same problem with GetCapabilities can be avoided by adding an “ows_extent” metadata element to the WMS service configuration. Thus the extents are returned directly. Perhaps something similar is possible with Geoserver as well.
While I am configuring Oracle FeatureTypes for Geoserver I have to write the extents manually because the extent query takes too long and fails. Fortunately it is possible to do it manually with the administration utility.
Regards,
-Jukka Rahkonen-