GeoWebCache is a tile caching server implemented in Java that provides various tile caching services like WMS-C, TMS, WMTS, Google Maps, MS Bing and more
Home Page: https://www.geowebcache.org
The release process is managed by the sibling repository at https://github.com/GeoWebCache/gwc-release
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
The EPSG says EPSG:3857 is the identifier for web mercator. ArcGIS 10 says either of EPSG:102113 or EPSG:102100 identifies web mercator (see this post). The "community" says EPSG:900913 identifies web mercator.
Would it be possible for GeoWebCache to treat these identifiers as equivalent when included in a WMS request?
http://geowebcache.org/docs/current/configuration/diskquotas.html#disk-block-size says you need to specify a fixed block size. What happens if you can't?
For example, ZFS has variable-size blocks.
Would be nice if the docs advised what to do and what to expect in this case.
This is due to TileRangeIterator missing right/top border tiles at each zoom level if not using meta tiling, and for the method that calculates how many tiles are in a meta tile to return zero if metatiling factors are [1,1]
While profiling GWC, I saw that tiles read from the file system are written to a temporary file for caching by the PNGImageReader. This slowed down the application and seems quite unnecessary since the tiles are already stored as files. I patched GWC to call ImageIO.setUseCache(false), and it behaved much better. So I was thinking that maybe this should be default behavior of GWC.
In some cases it can be very useful to serve tiles from the cache only, i.e. only tiles that have been explicitly created through seeding. When a client requests a tile and the tile is in the cache that tile is returned immediately. If the tile is not in the cache then a blank tile is returned (i.s.o implicitly seeding the tile). In some cases a 404 return could trigger a client to show a blank tile locally.
This feature can be useful in cases where overlay tiles have sparsely distributed data. Think of GPS traces or other time-based phenomena. In the current GWC version one can configure an extent within a grid: when a tile is requested outside of that extent a blank tile is returned. This is basically the behaviour I am seeking but then for any tile that is not in the cache. This could save in cases an enormous amount of WMS backend requests, storage of blank tiles, etc. In particular once GWC will support seeding for multiple polygons.
In particular this feature is the most useful when a GeoRSS feed is used to do incremental seeding based on mutations in a backend dataset served through a WMS. If the backend geodata would have date of creation timestamps then the tilecache could be seeded by polygons in the GeoRSS feed until the current time is reached. From then on any mutations to that dataset (adds, deletes, updates) can be synchronized through that GeoRSS feed.
I hope the above clarifies the feature I am seeking. The implementation can be simple. I have been testing successfully on 1.3-SNAPSHOT. Basically if have used the
with rules like where -5 denotes a value to not expire the cache but return a blank tile when the tile is not in the cache. (The value -6 denotes the same condition but sends a 404). GeoWebCacheDispatcher.handleServiceRequest() basically checks on that layer config value and if the tile is not in the cache a blank tile (or 404) is returned. I have the implementation in a github clone. Possibly using expirationRule is not optimal.
Every time a tile is added/removed an event is sent, and the DiskQuota monitor takes it to update the usage statistics. The way it's implemented may add some significant overhead to the process. Something like 25% if the WMS latency tends to zero. Which is never the case but as things tend to grow exponentially here and this is related to synchronization issues it's gonna be better to solve it.
(btw, usage statistics are kept in a separate store than the tile metastore because:
a) they're maintained in a tile-page basis, not per single tile
b) they're independent of the life cycle of each tile (like in they relate to the life cycle of the layer, not each individual tile, so deleting/re-seeding a given tile does not change the fact that that region is being queried more/less often by users of the layer)
c) I wanted to be able of keeping track of disk usage even when the metastore is disabled (which happens in most of the production environments I know of)
There are a number of non daemon threads in GWC that are not being correctly shut down:
Seeding against a WMS that's behind http basic authentication looks like GWC is sending each GetMap two times, first without credentials and next with them.
Index: src/main/java/org/geowebcache/layer/TileLayerDispatcher.java
===================================================================
--- src/main/java/org/geowebcache/layer/TileLayerDispatcher.java (revision 1188)
+++ src/main/java/org/geowebcache/layer/TileLayerDispatcher.java (working copy)
@@ -62,16 +62,26 @@
this(gridSetBroker, configs, 2);
}
- public TileLayerDispatcher(GridSetBroker gridSetBroker, List<Configuration> configs,
- int loadDelay) {
+ public TileLayerDispatcher(GridSetBroker gridSetBroker, List<Configuration> configs,int loadDelay) {
+
this.gridSetBroker = gridSetBroker;
this.configs = configs;
- ThreadFactory tfac = new CustomizableThreadFactory("GWC Configuration loader thread");
- configLoadService = Executors.newSingleThreadExecutor(tfac);
- ConfigurationLoader loader = new ConfigurationLoader(this, loadDelay);
- configurationLoadTask = configLoadService.submit(loader);
+ if (loadDelay > -1) {
+ ThreadFactory tfac = new CustomizableThreadFactory("GWC Configuration loader thread");
+ configLoadService = Executors.newSingleThreadExecutor(tfac);
+ ConfigurationLoader loader = new ConfigurationLoader(this, loadDelay);
+ configurationLoadTask = configLoadService.submit(loader);
+ }
+ else {
+ try {
+ configuredLayers = new ConfigurationLoader(this, loadDelay).call();
+ }
+ catch (Exception e) {
+ throw new RuntimeException(e);
+ }
+ }
}
public TileLayer getTileLayer(String layerIdent) throws GeoWebCacheException {
I found some broken links inside the documentation, which refer to the old Trac.
An enabled property for TileLayer.
Its purpose is not only to save a couple keystrokes to comment it out in geowebcache.xml, but to allow to temporarily disable a layer while still being able to perform a seed job against it.
A new element true|false will be added to the geowebcache.xsd schema allowing to set the enabled property for a layer.
A disabled layer will not be listed in capabilities documents, and any attempt to perform a request against it will result in an exception.
Yet, the administrator will be able to seed/truncate it both through the web ui and through a REST call.
in my config layer has:
expireCacheList with only one node expirationRule with attrs minZoom="0" and expiration="43200"
then if we seed 0-4 lavels and go to preview we will see that tiles will loads from backend wms (profiling backend wms) but if we change expiration to expiration="43200000" tiles will immidiatly apears after reload config (loads from cache).
so i think there are an issue about how it works. docs told us that expiration sets in seconds but it doesn't work (new tiles will loads from backend wms)
When enabling tile expiry using a GeoRSS feed, the variable lastUpdate is initially empty. After each feed request from the remote GeoRSS provider the value is set to the date/time of the latest GeoRSS entry and can be supllied on the next feed request via variable substitution of the ${lastUpdate} variable in the feedUrl config element. This works as expected.
The problem is that on each GWC restart the internal variable "lastUpdate" is reset to empty/null such that the entire tile expiry/reseeding restarts from "day 0". The solution is to make the "lastUpdate" variable persistent per layer.
The relevant file is org.geowebcache.georss.GeoRSSPollTask in module gwc-georss. The "lastUpdate" is maintained in the member variable private String lastUpdatedEntry = ""; Where/how to make this variable persistent remains to be seen: in Metastore or in Tilestore ?
As described in this post : http://old.nabble.com/Problem-using-regexParameterFilter-between-wms-and-gmaps-td27231996.html gwc currently is missing the support for the CQL_FILTER parameter for Google Maps requests.
It happens that sometime threads can not be killed from the /rest/seed/LayerName webpage by pressing 'Kill Thread' button.
There seems to be some kind of lock.
We have several instances of gwc running on different servers, all using the same metastore and blobstore.
We are not sure this is the root cause and have not been able to reproduce this error.
Nevertheless we decided to report this issue.
Hi
GWC redirect such getfeatureinfo request:
http://192.168.1.102:8080/geoserver/gwc/service/wmts?SERVICE=WMTS&REQUEST=GetFeatureInfo&VERSION=1.0.0&LAYER=adms_a&STYLE=_null&TILEMATRIXSET=PUWG_1992&TILEMATRIX=PUWG_1992%3A4&TILEROW=1&TILECOL=2&FORMAT=image%2Fgif&INFOFORMAT=text%2Fhtml&I=255&J=169
to WMS server with changed/incorrect FORMAT parameter:
192.168.1.102/cgi-bin/wms?SERVICE=WMS&REQUEST=GetFeatureInfo&VERSION=1.1.1&LAYERS=adms_a&QUERY_LAYERS=adms_a&EXCEPTIONS=application/vnd.ogc.se_xml&STYLES=&INFO_FORMAT=text/html&FORMAT=text/html&SRS=EPSG:2180&HEIGHT=256&WIDTH=256&BBOX=699296.0,304256.0,699424.0,304384.0&X=13&Y=122
It causes an error in WMS server.
The FORMAT parameter should be the same in WMSgetfeatureinfo as in WMTSgetfeatureinfo request.
Best Regards
Bartek
When the GeoRSSTileRangeBuilder encounters multiple entries in a GeoRSS feed it will let the GeometryRasterMaskBuilder aggregate the entries' geometries by expanding an initial Envelope from the first entry. In some cases like when geometries in the GeoRSS entries are widely dispersed e.g. around the globe, this will truncate/seed much more tiles than neccessary. Most of these tiles may be blanc.
The current implementation is as follows: for each entry GeoRSSTileRangeBuilder will call GeometryRasterMaskBuilder.setMasksForGeometry(geometry). setMasksForGeometry() maintains a variable "Envelope aggregatedGeomBounds" which it will expand after initial creation by calling expandToInclude() on this Envelope.
This behaviour (tiles reseeded for the aggregate Envelope of all Polygons) can be observed when constructing a GeoRSS feed that provides multiple Polygon entries in a single feed response. When the same feed is provided by a single subsequent Polygon entry in each feed response, only the tile area of each Polygon Envelope is reseeded. This is IMO the expected/wanted behaviour in many if not all cases.
The solution is to only build masks for each geometry, at least with Polygons. Points may be a special case.
While developing the diskquota module I didn't want to rely on H2 for the storage of page usage stats as the final goal is to make it work on a clustered environment.
Yet the functionality needed to be tested and it was released for "beta testing" with a very dumb storage implementation based on serialization of page objects.
It's time to make this better as there're are already production deployments that want to incorporate the disk quota capabilities.
Part of the issue seems to have been introduced at 7005140#L4R116
In any case, it's weird to see negative estimated time remaining and bad tile counts
The caching of a layer in Mapserver (ms4w 3.0.2) with GeoWebCache 1.2.6 fails when displaying the layer through the OpenLayers demo. All the tiles displayed are broken. Mapserver seems to work correctly, since it generates the GetCapabilities without problems and the GetMap requests display correctly the layer. I have tried to add extra parameters to the 5th constructor-arg of the gwcWMSConfig bean with the same result (adding there the map parameter does not seem to make any difference). At gwc startup everything is normal.
Below you can find the error shown in the log for each tile and the gwcWMSConfig bean. The getcapabilities document generated by Mapserver can be found at https://gist.github.com/1037624.
Issued as a consequence of the post "GeoWebcache and Mapserver throws Invalid URI - Invalid Query" in [email protected].
ArcGIS tiling schemes are supported with their default layout. Yet it's common to separate out the location of the conf.xml file and the actual tiles directory, so we want a separate arcgisLayer option to specify the location of the actual tiles and not only conf.xml
run gwc with meta distabled, seed, enable it, truncate: no luck
Renaming a layer at runtime implies:
This is in order to account for layer name changes in GeoServer without loosing the cache nor the stats.
It would be great if admins could set the service metadata such as a title, abstract, owner, access constraints etc. in the configuration. In 1.2.2 the title for services is "Note that not all GeoWebCache instances provide a full WMS service". This information is used on mapping sites so it would be good if it wasn't hard-coded.
The DiskQuota "page store" uses a Berkeley DB JE database, but at the moment is not coded to support clustering/HA. This means load balanced deployments are limited in its ability to hit a shared cache directory, as only one of them will block the page store and the others will block themselves.
This is not much of a problem for standalone GWC as it's as easy as getting rid of the gwc-diskquota.jar library and it's diskquota is completely gone, but is more difficult for the GeoServer integrated GWC as the configuration UI is a single module and depends on the gwc diskquota module.
So an environment variable similar to GWC_METASTORE_DISABLED was proposed on the GeoServer mailing list to support load balanced deployments of GeoServer. See http://jira.codehaus.org/browse/GEOS-4454 for reference.
Getting this error from GeoRSSPollTask (GWC 1.2.5):
12 Apr 21:37:32 ERROR [georss.GeoRSSPollTask] - Error encountered trying to poll the GeoRSS feed http://localhost/gr?cmd=feed-get-req&feed=bla. Another attempt will be made after the poll interval of 2 Minutes, 30 Seconds
java.lang.IllegalArgumentException: timeout value is negative
at java.lang.Thread.join(Thread.java:1205)
at org.apache.commons.httpclient.util.TimeoutController.execute(TimeoutController.java:63)
at org.apache.commons.httpclient.util.TimeoutController.execute(TimeoutController.java:82)
at org.apache.commons.httpclient.protocol.ControllerThreadSocketFactory.createSocket(ControllerThreadSocketFactory.java:95)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:128)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.geowebcache.georss.GeoRSSReaderFactory.createReader(GeoRSSReaderFactory.java:50)
at org.geowebcache.georss.GeoRSSPollTask.runPollAndLaunchSeed(GeoRSSPollTask.java:134)
at org.geowebcache.georss.GeoRSSPollTask.run(GeoRSSPollTask.java:102)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
IMO this is because the timeout value is set in
https://github.com/GeoWebCache/geowebcache/blob/master/geowebcache/georss/src/main/java/org/geowebcache/georss/GeoRSSReaderFactory.java
line 41: builder.setBackendTimeout(120 * 1000);
and then in
https://github.com/GeoWebCache/geowebcache/blob/master/geowebcache/core/src/main/java/org/geowebcache/util/HttpClientBuilder.java
line 120: this.backendTimeout = backendTimeout * 1000;
and then again on
line 131: params.setConnectionTimeout(backendTimeout * 1000);
All in all this multiplies to:
120 * 1000 * 1000 * 1000 which overflows the int, rendering backendTimeout negative.
Seeding (not reseeding) unnecessarily reads the existing tiles into memory, causing both heap garbage and excessive disk activity.
from the mailing list: http://sourceforge.net/mailarchive/message.php?msg_id=27792705
docs says it's not possible to set a global disk quota. They need to be updated cause it is possible to set a global quota now.
migrate svn repo to github maintaining the full branches and tags history
now that we gather LRU/LFU usage stats it should be as easy as reverting the order to get MOST Recently/Frequently used tile pages and use them for priority seeding
Problem reported in http://jira.codehaus.org/browse/GEOS-4492
Assessed it only manifests if native JAI is not installed, seems to be a problem with the com.sun.imageio.plugins.jpeg.JPEGImageWriter not supporting cropped RenderedImages when MetaTile writes single tiles out of the meta tile image.
Note: this may be a regression.
follow discussion on the mailing list: http://old.nabble.com/caching-with-parameter-filters-td31273681.html#a31273681
Stale thread local variables are kept around if WMSLayer.getTile is called and it needs to go to the backend due to a cache miss.
May cause trouble to app hot deploy on tomcat
We're using GeoWebCache 1.2.2 as a WMTS-server. We are very happy about it, but we have come across a couple of minor issues.
I have made a fix (based on 1.2.2 sources) in WMTSService.java, and I have merged the fixes with the version of WMTSService.java found in the master-branch. That is, I have a diff file with the changes.
I'm not familiar with Git, so please advise if this is the correct way to submit patches...
The issues are described below (as previously posted to the developer mailing list):
Hi All:
I encountered a big problem that Tomcat hangs when the {tomcat_home}/logs/catalina.out finally display [layer.TileLayerDispatcher] - ConfigurationLoader woke up, initializing
After installing tomcat on CentOS x86_64 and placing geoserver.war(2.0.3) and geowebcache.war(1.2.4) into {tomcat_home}/webapps, The ONLY thing I did was modifying /webapps/geowebcache/WEB-INF/geowebcache-core-sevlet.xml, changing "" to "<ref bean="gwcWMSConfig" />" and changing "http://localhost:8282/geoserver" to "http://localhost:8080/geoserver".
2011-4-22 0:05:57 org.apache.catalina.core.AprLifecycleListener init
信息: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/jre1.6.0_24/lib/amd64/server:/usr/local/jre1.6.0_24/lib/amd64:/usr/local/jre1.6.0_24/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
2011-4-22 0:05:58 org.apache.coyote.AbstractProtocolHandler init
信息: Initializing ProtocolHandler ["http-bio-8080"]
2011-4-22 0:05:58 org.apache.coyote.AbstractProtocolHandler init
信息: Initializing ProtocolHandler ["ajp-bio-8009"]
2011-4-22 0:05:58 org.apache.catalina.startup.Catalina load
信息: Initialization processed in 2181 ms
2011-4-22 0:05:58 org.apache.catalina.core.StandardService startInternal
信息: Starting service Catalina
2011-4-22 0:05:58 org.apache.catalina.core.StandardEngine startInternal
信息: Starting Servlet Engine: Apache Tomcat/7.0.12
2011-4-22 0:05:59 org.apache.catalina.startup.HostConfig deployWAR
信息: Deploying web application archive geowebcache.war
22 四月 00:06:01 INFO [context.ContextLoader] - Root WebApplicationContext: initialization started
22 四月 00:06:01 INFO [support.XmlWebApplicationContext] - Refreshing org.springframework.web.context.support.XmlWebApplicationContext@288b567c: display name [Root WebApplicationContext]; startup date [Fri Apr 22 00:06:01 CST 2011]; root of context hierarchy
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/acegi-config.xml]
22 四月 00:06:02 INFO [support.XmlWebApplicationContext] - Bean factory for application context [org.springframework.web.context.support.XmlWebApplicationContext@288b567c]: org.springframework.beans.factory.support.DefaultListableBeanFactory@317cfd38
22 四月 00:06:02 INFO [support.DefaultListableBeanFactory] - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@317cfd38: defining beans [filterChainProxy,restFilterInvocationInterceptor,restFilterDefinitionMap,httpSessionContextIntegrationFilter,basicProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,authenticationEntryPoint,authenticationManager,daoAuthenticationProvider,simpleUserDetailsService,httpRequestAccessDecisionManager,roleVoter]; root of factory hierarchy
22 四月 00:06:02 INFO [config.PropertiesFactoryBean] - Loading properties file from ServletContext resource [/WEB-INF/users.properties]
22 四月 00:06:02 INFO [memory.UserMap] - Adding user [org.acegisecurity.userdetails.User@0: Username: geowebcache; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_ADMINISTRATOR]
22 四月 00:06:02 INFO [intercept.AbstractSecurityInterceptor] - Validated configuration attributes
22 四月 00:06:02 INFO [context.ContextLoader] - Root WebApplicationContext: initialization completed in 1007 ms
22 四月 00:06:02 INFO [servlet.DispatcherServlet] - FrameworkServlet 'geowebcache': initialization started
22 四月 00:06:02 INFO [support.XmlWebApplicationContext] - Refreshing org.springframework.web.context.support.XmlWebApplicationContext@52234265: display name [WebApplicationContext for namespace 'geowebcache-servlet']; startup date [Fri Apr 22 00:06:02 CST 2011]; parent: org.springframework.web.context.support.XmlWebApplicationContext@288b567c
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-servlet.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-core-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-georss-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-gmaps-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-kmlservice-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-rest-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-tmsservice-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-virtualearth-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-wfsclient-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-wmsservice-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-wmtsservice-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-diskquota-context.xml]
22 四月 00:06:02 INFO [xml.XmlBeanDefinitionReader] - Loading XML bean definitions from ServletContext resource [/WEB-INF/geowebcache-arcgiscache-context.xml]
22 四月 00:06:02 INFO [support.XmlWebApplicationContext] - Bean factory for application context [org.springframework.web.context.support.XmlWebApplicationContext@52234265]: org.springframework.beans.factory.support.DefaultListableBeanFactory@4440ece0
22 四月 00:06:03 INFO [support.DefaultListableBeanFactory] - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@4440ece0: defining beans [gwcAppCtx,gwcXmlConfig,gwcWMSConfig,gwcTLDispatcher,gwcDefaultStorageFinder,gwcMetaStore,gwcBlobStore,gwcStorageBroker,gwcGridSetBroker,gwcRuntimeStats,geowebcacheDispatcher,gwcSeederThreadPoolExec,gwcTileBreeder,gwcProxyDispatcher,gwcGeoRSSPoller,gwcServiceGMaps,gwcServiceMGMaps,gwcServiceKML,gwcSeedRestlet,gwcSeedFormRestlet,gwcReloadRestlet,gwcTileLayerRestlet,gwcBoundsRestlet,gwcFilterUpdateRestlet,gwcByteStreamerRestlet,gwcRestDispatcher,gwcRESTUrlMapping,gwcServiceTMS,gwcServiceVE,gwcServiceWFS,gwcServiceWMS,gwcServiceWMTS,DiskQuotaConfigLoader,DiskQuotaMonitor,pageStore,ExpirationPolicyLRU,ExpirationPolicyLFU,arcGisLayerConfigurationExtention,gwcUrlMapping]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@317cfd38
22 四月 00:06:03 INFO [storage.DefaultStorageFinder] - ***********************************************************************************************************************************
22 四月 00:06:03 INFO [storage.DefaultStorageFinder] - *** Reverting to java.io.tmpdir /usr/local/apache-tomcat-7.0.12/temp/geowebcache for storage. Please set GEOWEBCACHE_CACHE_DIR. ***
22 四月 00:06:03 INFO [storage.DefaultStorageFinder] - ***********************************************************************************************************************************
22 四月 00:06:03 INFO [config.XMLConfiguration] - No configuration directory was specified, using /usr/local/apache-tomcat-7.0.12/webapps/geowebcache/WEB-INF/classes/geowebcache.xml
22 四月 00:06:03 INFO [config.XMLConfiguration] - Found configuration file in /usr/local/apache-tomcat-7.0.12/webapps/geowebcache/WEB-INF/classes
22 四月 00:06:03 INFO [config.XMLConfiguration] - Updating configuration from 1.2.2 to 1.2.4
22 四月 00:06:04 INFO [config.XMLConfiguration] - cvc-elt.1: Cannot find the declaration of element 'gwcConfiguration'.
22 四月 00:06:04 INFO [config.XMLConfiguration] - Will try to use configuration anyway.
22 四月 00:06:04 WARN [grid.GridSetFactory] - GridSet EPSG:2163 was defined without metersPerUnit, assuming 1m/unit. All scales will be off if this is incorrect.
22 四月 00:06:04 INFO [config.XMLConfiguration] - Read GridSet EPSG:2163
22 四月 00:06:04 INFO [config.GetCapabilitiesConfiguration] - Constructing from url http://localhost:8080/geoserver/wms?request=getcapabilities&version=1.1.0&service=wms
22 四月 00:06:04 INFO [layer.TileLayerDispatcher] - ConfigurationLoader acquired lock, sleeping 2 seconds
22 四月 00:06:05 INFO [jdbc.JDBCMBWrapper] - MetaStore database is version 120
22 四月 00:06:05 INFO [georss.GeoRSSPoller] - Initializing GeoRSS poller...
22 四月 00:06:06 INFO [layer.TileLayerDispatcher] - ConfigurationLoader woke up, initializing
The Order of layers shown in getCapabilities is different to how they are set up in the config file. For example, I have a bunch of layers in my config file ordered chronologically, however they are all jumbled up in the capabilities doc. When they are shown on a layer chooser using this order, they are shown to the user in random order.
SeedRequest.getType() lacks a conversion from the literal "truncate" to the enumerated element TRUNCATE, making any truncate request issued through the RESTish interface to be treated as a seed request instead.
(aside: I don't understand why anything but "seed" and "reseed" is being taken as if it were a seed request, with the following entry in the logs: log.warn("Unknown type ""+type+"", assuming seed");
IMHO an error should be thrown.
It should allow to set:
The coordinates that geowebcache sends for a getFeatureInfo request are incorrect.
This was working properly at around 24 Jan 2011, I think 1.2.2 had it working.
1.2.6 is broken.
http://maps.opengeo.org/geowebcache/demo/openstreetmap?gridSet=EPSG:4326&format=image/png
If you click on Brazil you will get a getfeatureinfo response from russia.
Users reporting the seeding thread dying at the first failed WMS request being way too inconvenient, specially when running long seeds, because eventually all the threads die and the seed task needs to be relaunched.
It would be better if:
a) The seeder retries a failed request
b) After a couple retries it skips that (meta)tile and goes on
c) It waits for some time before re-issuing the request
d) It's all configurable
It would be handy to be able to set more layer information such as Default WMS Path and Attribution Information.
Going one step further, all of the layer metadata could be retrieved from the WMS if that were put in as an option to do so. You could not only get the layer name, title, abstract, etc but also the layer bounds and have the admin only have to set the URL to the WMS and the layer name in the config.
This could be the default behaviour and give the administrator have the ability to override the layer metadata in the config file, similar to how layer metadata is currently set.
The acegi dependency being on the rest module (as well as the two acegi related classes) is a mistake. The rest module is independent of the security implementation and so it should be. I'll move the acegi dependency to the web module.
We want to use gwc and monitor and control it from an external program.
When a rest/seed/ POST request is issued , we want to receive back id's for each thread/task busy truncating or seeding the layer.
These id's can subsequently be used in a rest/seedprogress/{task_ids} and rest/seedcancel/{task_ids} GET request. to monitor the progress for a layer and to be able to stop the tasks for this layer.
An external program or script can thus start a seed task, monitor it and stop it if needed.
A seedprogress request should return information like we see on the /rest/seed/LayerName webpage like 'time remaining', 'running status', 'Tiles completed'.
A seedcancel request should return information whether the thread/task was cancelled succesfully.
NTLM proxies that require authentication can't be used with the "proxyUrl" element in a WMS layer configuration. More details and patch at https://sourceforge.net/mailarchive/forum.php?thread_name=30024986.post%40talk.nabble.com&forum_name=geowebcache-users
Nightly build in Hudson reports success but they're failing and not being uploaded to the repo
I wrote some munin plugins for GeoWebCache you can find at http://bit.ly/lbjKvh . I parsed the html output that is not the best for future release.
If it's possible to have and more parsable output it will stabilize the monitoring, something like Tomcat do with the optionnal 'manager/status?XML=true' is interesting.
The fix for #2 came thru to enable geoserver to initialize on a single thread but it doesn't address the concern and might actually cause GWC to fail with an NPE on TileLayerDispatcher.reinit()
There's no point in having loadDelay on TileLayerDispatcher. Just move it to GetCapabilitiesConfiguration where it'll die anyways as nobody is gonna use that configuration anymore?
Hello,
I have a problem with the generation of the cache in PNG format. All the images are created but they can't be opened by any picture viewer. No errors are written in the log file and the generation in the JPEG format has no problems.
I'm using GWC inside GEOSERVER version 2.1-RC3. It runs over jboss 5.0.1 with jvm 1.6.0_23. The source geometries are coming from an ORACLE database. With the previous version of GWC and GEOSERVER everything goes good but I need to get this newer version.
What can I do to resolve the problem?
We would like to see proper realization of png8 semi-transparent images.
JAI handles fully transparant images, but not semi-transparant properly.
The only program we know that does a proper conversion from png to png8, is the external program pngquant.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.