Workspaces¶
This section describes how to view and configure workspaces. Analogous to a namespace, a workspace is a container which organizes other items. In GeoServer, a workspace is often used to group similar layers together. Layers may be referred to by their workspace name, colon, layer name (for example topp:states). Two different layers can have the same name as long as they belong to different workspaces (for example sf:states and topp:states).
Workspaces page¶
Add a Workspace¶
The buttons for adding and removing a workspace can be found at the top of the Workspaces view page.
Buttons to add and remove¶
To add a workspace, select the Add new workspace button. You will be prompted to enter the the workspace name and URI (as described in Edit a Workspace below).
New Workspace page with example¶
Remove a Workspace¶
To remove a workspace, select it by clicking the checkbox next to the workspace. Multiple workspaces can be selected, or all can be selected by clicking the checkbox in the header. Click the Remove selected workspaces(s) button. You will be asked to confirm or cancel the removal. Clicking OK removes the selected workspace(s).
Workspace removal confirmation¶
Edit a Workspace¶
To view or edit a workspace, click the workspace name. A workspace configuration page will be displayed.
Workspace named “topp”¶
A workspace is defined by a name and a Namespace URI (Uniform Resource Identifier). The workspace name is limited to ten characters and may not contain space. A URI is similar to a URL, except URIs do not need to point to a actual location on the web, and only need to be a unique identifier. For a Workspace URI, we recommend using a URL associated with your project, with perhaps a different trailing identifier. For example, http://www.openplans.org/topp is the URI for the “topp” workspace.
Root Directory for REST PathMapper¶
Workspace Root Directory parameter¶
This parameter is used by the RESTful API as the Root Directory for uploaded files, following the structure:
${rootDirectory}/workspace/store[/<file>]
Note
This parameter is visible only when the Enabled parameter of the Settings section is checked.
Workspace Settings¶
Use Enabled checkbox to override the global contact information for this this workspace.
Enable workspace settings to provide default contact information¶
Clients accessing this workspace as a Virtual Services will use the contact information provided here.
Workspace Services¶
Use the checkbox located next to each serivce to override the global settings for the associated service.
Enable workspace services to provide default service description¶
Once enabled clicking on the service link will open the settings page for the service, allowing default values for service title, abstract and other details to be supplied.
Workspace WMS Settings¶
Clients accessing this workspace as a Virtual Services will use the service description provided here.
Security¶
The Security tab allows to set data access rules at workspace level.
Note
For more information on data access rules, please see the section on Data.
To create/edit the workspace’s data access rules, check/uncheck checkboxes according to the desired role. The Grant access to any role checkbox grant each role for any access mode.
Isolated Workspaces¶
Isolated workspaces content is only visible and queryable in the context of a virtual service bound to the isolated workspace. This means that isolated workspaces content will not show up in global capabilities documents and global services cannot query isolated workspaces contents. Is worth mentioning that those restrictions don’t apply to the REST API.
A workspace can be made isolated by checking the Isolated Workspace checkbox when creating or editing a workspace.
Making a workspace isolated¶
An isolated workspace will be able to reuse a namespace already used by another workspace, but its resources (layers, styles, etc …) can only be retrieved when using that workspace virtual services and will only show up in those virtual services capabilities documents.
It is only possible to create two or more workspaces with the same namespace in GeoServer if only one of them is non isolated, i.e. isolated workspaces have no restrictions in namespaces usage but two non isolated workspaces can’t use the same namespace.
The following situation will be valid:
Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: true
Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true
But not the following one:
Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: false
Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true
At most only one non isolated workspace can use a certain namespace.
Consider the following image which shows to workspaces (st1 and st2) that use the same namespace (http://www.stations.org/1.0) and several layers contained by them:
Two workspaces using the same namespace, one of them is isolated.¶
In the example above st2 is the isolated workspace. Consider the following WFS GetFeature requests:
The first request is targeting WFS global service and requesting layer2, this request will use layer2 contained by workspace st1. The second request is targeting st2 workspace WFS virtual service, layer2 belonging to workspace st2 will be used. Request three and four will use layer2 belonging to workspace, respectively, st1 and st2. The last two requests will fail saying that the feature type was not found, isolated workspaces content is not visible globally.
The rule of thumb is that resources (layers, styles, etc …) belonging to an isolated workspace can only be retrieved when using that workspaces virtual services and will only show up in those virtual services capabilities documents.