thanks Stefan, look forward to a report, which we'll put in the planning
pipeline! I;'m rather hoping for some dumb stuff to emerge, that we can fix
easily.
current performance seems adequate for data transfer use, WMS tends to be
used more interactively, so it will be useful to apply the tools e
Community schemas ignores maxFeatures
-
Key: GEOS-1930
URL: http://jira.codehaus.org/browse/GEOS-1930
Project: GeoServer
Issue Type: Bug
Components: Community schema
Affects Versions: 1.6.x
Community schemas GetCapabilites does not work
--
Key: GEOS-1929
URL: http://jira.codehaus.org/browse/GEOS-1929
Project: GeoServer
Issue Type: Bug
Components: Community schema
Affects
Community schemas DescribeFeatureType does not work
---
Key: GEOS-1928
URL: http://jira.codehaus.org/browse/GEOS-1928
Project: GeoServer
Issue Type: Bug
Components: Community schema
Hi Cameron,
On 1.6.x there is the "stress" community module. It basically contains
some code which uses a freemarker template to whip up a jmeter script
which executes a bunch of random wms requests. We used it for our WMS
performance benchmarking we did last year. Once you have the jmeter
scr
WMS is not currently supported in this build., We decided to wait until the
trunk was ready and port to it rather than clone and hack the WMS module.
(AWDIP services are about data transfer, not visualisation), they need to be
judged against the requirements for this, so in fact blinding speed is
Good stuff.
Gabriel may have further insights, but here's my perspective on what might
be worth considering:
1) No serious profiling work has been done on this build, and it wouldnt
suprise me if significant gains can be made
2) Fixes should target the trunk, so we'll need to re-run the profiling
Cameron Shorter wrote:
> As part of our robustness testing of AWDIP deployments of Geoserver
> (which includes Community Schemas), we have signed up to do "White box
> testing". Ie, work out what is happening inside Geoserver for the AWDIP
> use cases.
> The end goal is to identify areas in the
As part of our robustness testing of AWDIP deployments of Geoserver
(which includes Community Schemas), we have signed up to do "White box
testing". Ie, work out what is happening inside Geoserver for the AWDIP
use cases.
The end goal is to identify areas in the code where performance can be
im
[
http://jira.codehaus.org/browse/GEOS-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Aime reopened GEOS-1925:
---
Reopening to edit the "fix for" field
> PointSymbolizer on polygon features results in an icon at the edge of t
Point placement ruined when previous polygon symbolizer is used
---
Key: GEOS-1927
URL: http://jira.codehaus.org/browse/GEOS-1927
Project: GeoServer
Issue Type: Bug
Affects Vers
Uninstall of GeoServer removes %GEOSERVER_DATA_DIR% environment variable
Key: GEOS-1926
URL: http://jira.codehaus.org/browse/GEOS-1926
Project: GeoServer
Issue Type: Im
PointSymbolizer on polygon features results in an icon at the edge of the
polygon (should be inside)
Key: GEOS-1925
URL: http://jira.codehaus.org/browse/GEOS-1925
GetFeatureInfo returns text response when the format is not recognize,
shouldn't it return an exception instead?
Key: GEOS-1924
URL: http://jira.codeh
Hi guys,
I made few improvements to the GeoServer RESTConfig and sldService stuff
which I would like to briefly discuss here, and in case of interest I can
commit it:
1. DataStoreFileResource: this class originally was intended to let
GeoServer get a shapefile and create a new datastore. I correc
15 matches
Mail list logo
