When GeoServer is initializing the Control Flow extension, it will log an
error message if the "ip.blacklist" and/or "ip.whitelist" properties are
used in controlflow.properties. For example,
ERROR [org.geoserver.flow.config] Rules should be assigned just a queue
size, instead ip.blacklist is
I downloaded the 10.47 MB GeoTIFF from here and loaded it into GeoServer:
http://www.naturalearthdata.com/downloads/50m-raster-data/50m-gray-earth/
I created a new style called contour_test (full SLD at the end). I then
used the following URLs against a GeoServer that is patched with the
I tested changing CELL_CENTER to CELL_CORNER and it only seemed to fix the
extra cropping about half of the time for me. The gap can be up to one
pixel width with the current code on master and changing CELL_CENTER to
CELL_CORNER reduces the gap to up to a half pixel width but does not
eliminate
I don't use the dynamic colormap module but the JIRA ticket in the first post
has a test case using it:
https://osgeo-org.atlassian.net/browse/GEOS-8070
Adding 1 to the envelope width and height here seems to fix the problem:
I've also seen issues with GeoServer potentially losing the right-most and
bottom-most pixels when using rendering transformations to style raster
data. I've reproduced this in 2.9.x and 2.10.x with GeoTIFF coverages and
with raster-to-raster and raster-to-vector transformations. This can create
Here is the pull request:
https://github.com/geoserver/geoserver/pull/2174
The build exceeding the time limit doesn't appear to be related.
Steve Ikeoka
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Regression-Accessing-Styles-Directory-tp5313244p5313486.html
Sent
I created a JIRA ticket https://osgeo-org.atlassian.net/browse/GEOS-8040 and
will try to submit a pull request today.
When these images are loaded for an output format like PNG or JPEG, the
images are loaded internally by the renderer and work fine since they do not
go through StylePublisher.
A regression with accessing the styles directory was introduced in GeoServer
2.9.2 and 2.10.0 as a result of fixing workspace styles for
https://osgeo-org.atlassian.net/browse/GEOS-7635. In previous versions, it
was possible to access files within subdirectories (e.g.,
I noticed two issues with specifying a layer name as part of a virtual
service that both seemed to be caused by line 63 in
org.geoserver.ows.OWSHandlerMapping not providing a workspace qualified
layer name:
if (catalog.getLayerByName(first) != null) {
Adding the workspace to the layer name seemed
JIRA Ticket:
https://osgeo-org.atlassian.net/browse/GEOS-7366
Pull Request:
https://github.com/geoserver/geoserver/pull/1391
Steve Ikeoka
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/WPS-File-Handle-Leak-tp5243846p5244010.html
Sent from the GeoServer - Dev mailing
There is a file handle leak when executing WPS processes with coverage input
in GeoServer 2.7.x. I don't see any changes on master or 2.8.x that would
have fixed this but I was hoping that someone could confirm this.
In order for a file handle leak to occur, the process must have one or more
Is there a standard practice for unit testing concurrency issues in
GeoServer? I found an issue in
org.geoserver.wms.featureinfo.HTMLFeatureInfoOutputFormat.getTemplate that
could cause the wrong content template to be used if GeoServer is processing
multiple WMS GetFeatureInfo requests with HTML
In org.geoserver.jdbcconfig.internal.ConfigDatabase, the add(T) method calls
new String(byte[]) using the default character set. Shouldn't it be called
using "UTF-8" encoding to be consistent with the save(T) method in the same
class and the mapRow method in
There is an extra double quotation mark in the GeoServer 2.7.2 LoggingFilter
output between the referrer and content type. For example,
127.0.0.1 "POST /geoserver/wps" "TestUserAgent" "" " "text/xml"
The extra double quotes were added when adding the content type for
14 matches
Mail list logo
