Re: [Geoserver-users] GeoServer 2.11.1 OpenLayers CRS Warnings

I just created a new ticket for this issue: https://osgeo-org.atlassian.net/browse/GEOS-8178 Steve Ikeoka -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GeoServer-2-11-1-OpenLayers-CRS-Warnings-tp5323388p5323700.html Sent from the GeoServer - User mailing list archive at

Re: [Geoserver-users] GeoServer 2.11.1 OpenLayers CRS Warnings

I think that this warning originated with this commit to org.geotools.referencing.factory.URN_Parser: https://github.com/geotools/geotools/commit/a63c0d9ec83e882eb1b876d909bebe3ab1692913 For some reason, OpenLayersMapOutputFormat has always added "EPSG:" to the beginning of the code: String code

[Geoserver-users] GeoServer 2.11.1 OpenLayers CRS Warnings

After upgrading to GeoServer 2.11.1, I am getting the warning and stack trace below for WMS GetMap requests for the OpenLayers format using EPSG:4326. It doesn't appear to break anything and I verified that this warning does not occur in 2.10.3. I am unable to test 2.11.0 because it is not in

Re: [Geoserver-users] Multiple Layers in WMS GetFeatureInfo Requests

I can't test 2.11.0 because of the Maven repo problem but I reviewed the fix for GEOS-8005 and that appears to be an unrelated issue. This problem happens because org.geoserver.wms.map.GetMapKvpRequestReader.skipResource(Object) filters out the non-queryable layers and layer groups from the WMS

[Geoserver-users] Multiple Layers in WMS GetFeatureInfo Requests

When a WMS GetFeatureInfo request contains multiple layers or layer groups where at least one is queryable and one is not queryable, it appears that the filtering of the non-queryable layers and layer groups can cause the styles and cql_filter parameters to get mixed up. This can cause service

[Geoserver-users] RasterSymbolizer Env Function Doesn't Always Work

I've noticed that RasterSymbolizers sometimes ignore env parameters passed in the WMS request and use the default value instead. It appears that the env function works fine when the coverage is rendered on the direct raster path. I think that the env parameters from the request are not being

Re: [Geoserver-users] WPS Warnings - ApplicationContext is unset

JIRA Issue: https://osgeo-org.atlassian.net/browse/GEOS-8046 Pull Request: https://github.com/geoserver/geoserver/pull/2177 Steve Ikeoka -- View this message in context: http://osgeo-org.1560.x6.nabble.com/WPS-Warnings-Application-is-unset-tp5313517p5313723.html Sent from the GeoServer -

[Geoserver-users] WPS Warnings - Application is unset

org.geoserver.wps.ppio.ProcessParameterIO.findAll(Parameter, ApplicationContext) causes multiple warnings about the ApplicationContext being unset when it is called with a null ApplicationContext. It actually does two extension lookups, one for ProcessParameterIO and another for PPIOFactory, but

[Geoserver-users] YSLD Reference - Label Priority

The YSLD Reference incorrectly lists the label priority as the vendor option "x-labelPriority" but it is actually just a regular property "priority". Converting an SLD style to YSLD will use "priority" and attempting to use "x-labelPriority" doesn't do anything. SLD Reference:

Re: [Geoserver-users] YSLD Rule LegendGraphic Missing

I created a JIRA issue for this: https://osgeo-org.atlassian.net/browse/GEOT-5653 Steve Ikeoka -- View this message in context: http://osgeo-org.1560.x6.nabble.com/YSLD-Rule-LegendGraphic-Missing-tp5309253p5309434.html Sent from the GeoServer - User mailing list archive at Nabble.com.

[Geoserver-users] YSLD Rule LegendGraphic Missing

The SLD schema allows Rule elements to contain a LegendGraphic element but they are ignored when GeoServer converts an SLD style to YSLD. This is not currently implemented according to the YSLD Reference: http://docs.geoserver.org/latest/en/user/styling/ysld/reference/rules.html Example:

[Geoserver-users] Possible GeoServer 2.10.2 Regression

After upgrading from GeoServer 2.10.1 to 2.10.2, I am having an issue with continuous map wrapping not working for ImageMosaic and ImagePyramid coverages. With a -180,-90,180,90 coverage, the default OpenLayers preview loads an image between -270 to 270 but only the -270 to -180 part is rendered

Re: [Geoserver-users] Style Editor Preview Legend Errors

I am testing GeoServer 2.10.1. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Style-Editor-Preview-Legend-Errors-tp5307064p5307200.html Sent from the GeoServer - User mailing list archive at Nabble.com.

[Geoserver-users] Style Editor Preview Legend Errors

Using the Preview Legend feature on YSLD styles causes an XML parsing error "Content is not allowed in prolog" since org.geoserver.wms.web.data.StyleAdminPanel currently only handles SLD styles: StyleInfo si = new StyleInfoImpl(stylePage.getCatalog()); String styleName = "tmp" +

[Geoserver-users] Disabling WMTS in GeoServer 2.10

After upgrading to GeoServer 2.10.1, GeoServer is enabling WMTS every time it starts up. I can disable WMTS from the UI but it just gets re-enabled when I reload the server configuration or restart GeoServer. I think that line 38 in org.geoserver.gwc.wmts.WMTSXStreamLoader may be the cause of

[Geoserver-users] GeoServer GML 3 GeometryCollection Encoding

Which of these two GML 3 encodings of a GeometryCollection is correct? GeoServer 2.7.1 encodes a GeometryCollection containing a Polygon as: ... GeoServer 2.9.1 encodes it as: ... Also, it was mentioned in Andrea's comment on

Re: [Geoserver-users] Potentially Slow Mosaic Performance in directRasterRender

I found out that this issue will not happen when advanced projection handling is enabled because the GridCoverageRenderer method that is used in that path will always crop its final image. I was only able to reproduce this in a unit test by adding a @BeforeClass method with:

[Geoserver-users] Potentially Slow Mosaic Performance in directRasterRender

Some background: we are running GeoServer 2.7.2 and the map client is sending WMS GetMap requests for PNG output with transparent=TRUE against raster data using a simple ColorMap SLD and both tiled and non-tiled requests have been tested. We've noticed that the response time increases

Re: [Geoserver-users] Potentially Slow Mosaic Performance in directRasterRender

Also, this was tested with both bilinear and nearest neighbor interpolation and with mosaic native acceleration enabled and disabled. After more testing, I was able to track the slow performance down specifically to the javax.media.jai.ROIShape.getAsImage() call that occurs inside the

[Geoserver-users] ImageMosaic Logging

Several imagemosaic classes create their logger by calling toString() on the class instead of passing the class object directly to getLogger(). For example, org.geotools.util.logging.Logging.getLogger(ImageMosaicFormat.class.toString()); instead of

Re: [Geoserver-users] Code not closing CloseableIterator

JIRA ticket: https://osgeo-org.atlassian.net/browse/GEOS-7151 Pull request: https://github.com/geoserver/geoserver/pull/1181 Steve Ikeoka -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Code-not-closing-CloseableIterator-tp5073066p5219222.html Sent from the GeoServer -

Re: [Geoserver-users] Code not closing CloseableIterator

Even if all code that is calling the list() function always closes the returned CloseableIterator, the final CloseableIteratorAdapter instance that is created in SecureCatalogImpl.list() does not contain the reference to close the filteredWrapped CloseableIterator so filteredWrapped is left

Re: [Geoserver-users] Code not closing CloseableIterator

This warning might be coming from around line 1415 in the method: org.geoserver.security.SecureCatalogImpl.list(ClassT, Filter, Integer, Integer, SortBy) The following lines: return new CloseableIteratorAdapter(Iterators.filter(filteredWrapped,