Geosever阅读总结

      看英文文档，总是看得慢忘得快，看完一篇刚有点感觉，回头再接着深入，复习前面的时候发现已经是比较模糊了，还是要重头看起，边看边整理，不需要逐一翻译，只对内容做个总结，也许是一个不错的办法。下面是前段时间关于阅读geoserver时的一些简译。

 

Services

     GeoServer数据服务采用标准的OGC数据协议，wfs提供矢量数据服务，WMS提供地图数据服务，WCS提供栅格数据服务。

 

WFS basics

     WFS提供矢量数据的访问和操作，GeoServer 完全遵循OGC通信协议，包括基本操作，GetCapabilities, DescribeFeatureType and GetFeature，当然还有LockFeature and GetGmlObject高级功能。Wfs与GeoServer安全机制紧密结合，限制数据的访问和传输，支持多种输出格式。GeoServer还支持版本控制。

Differences between WFS versions

1.1.0和1.0.0默认的GML不同

空间坐标系有所改变

WFS output formats

WFS支持多种格式数据输出，输出语法如下：

outputFormat=<outputformat>

where <outputformat> is any of the options below.

Note

完全的列表可以在GetCapabilities.中看到

Format	Syntax	Notes
GML2	outputFormat=GML2	Default option using WFS 1.0.0
GML3	outputFormat=GML3	Default option using WFS 1.1.0
Shapefile	outputFormat=shape-zip	Created in a ZIP archive
JSON	outputFormat=json
CSV	outputFormat=csv

WFS vendor parameters

     Cql查询：GetFeature 请求数据，通过CQL查询，CQL不错，但不通过feature ID查询

     下面是一个简单的过滤查询：

      filter=%3CFilter%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CIntersects%3E%3CPropertyName%3Ethe_geom%3C/PropertyName%3E%3Cgml:Point%20srsName=%224326%22%3E%3Cgml:coordinates%3E-74.817265,40.5296504%3C/gml:coordinates%3E%3C/gml:Point%3E%3C/Intersects%3E%3C/Filter%3E

      同样的CQL查询：

      cql_filter=INTERSECT(the_geom,%20POINT%20(-74.817265%2040.5296504))

      Example

     Consider the following POST request:

     <wfs:GetFeature service="WFS" version="1.0.0" xmlns:wfs="http://www.opengis.net/wfs">

         <Query typeName="topp:states"/>

    </wfs:GetFeature>

    在GeoServer上这个请求是成功的

• 查询参数应该有wfs前缀
• 命名空间没有匹配uri

     

WFS reference

   Introduction

      OGC发布通过HTTP实现地理数据的发送和接收WFS标准。.

   Benefits of WFS

      Wfs使分析地图成为可能，wfs增强了数据的开发性.

   Operations

      WFS能够实现下列操作

Operation	Description
GetCapabilities	获得服务器数据，执行操作
DescribeFeatureType	获取数据集属性信息
GetFeature	获得真实的数据，包括属性值
LockFeature	阻止数据被修改
Transaction	编辑数据
GetGMLObject	(Version 1.1.0 only) - Retrieves element instances by traversing XLinks that refer to their XML IDs.

 

 

附英文原文：

Services¶

GeoServer serves data using standard protocols established by the Open Geospatial Consortium. The Web Feature Service (WFS) allows for requests of geographical feature data (vectors). The Web Map Service (WMS) allows for requests of images generated from geographical data. Finally, the Web Coverage Service (WCS) allows for requests of coverage data (rasters). These services are the heart of GeoServer.

WFS basics¶

GeoServer provides support for Open Geospatial Consortium (OGC) Web Feature Service (WFS) versions 1.0 and 1.1. This is a standard for getting raw vector data - the ‘source code’ of the map - over the web. Using a compliant WFS makes it possible for clients to query the data structure and the actual data. Advanced WFS operations also enable editing and locking of the data.

 

GeoServer is the reference implementation of both the 1.0 and 1.1 versions of the standard, completely implementing every part of the protocol. This includes the Basic operations of GetCapabilities, DescribeFeatureType and GetFeature, as well as the more advanced Transaction, LockFeature and GetGmlObject operations. GeoServer’s WFS also is integrated with GeoServer’s Security system, to limit access to data and transactions. It also supports a wide variety of WFS output formats, to make the raw data more widely available.

 

GeoServer additionally supports a special ‘versioning’ protocol in an extension: WFS Versioning. This is not yet a part of the WFS specification, but is written to be compatible, extending it to provide a history of edits, differences between edits, and a rollback operation to take things to a previous state.


Differences between WFS versions¶

The major differences between the WFS versions are:

WFS 1.1.0 returns GML3 as the default GML. In WFS 1.0.0 the default was GML2. (GeoServer still supports requests in both GML3 and GML2 formats.) GML3 has slightly different ways of specifying a geometry. 
In WFS 1.1.0, the way to specify the SRS (Spatial Reference System, aka projection) is urn:x-ogc:def:crs:EPSG:XXXX, whereas in version 1.0.0 the specification was http://www.opengis.net/gml/srs/epsg.xml#XXXX. This change has implications on the axis order of the returned data. 
WFS 1.1.0 supports on-the-fly reprojection of data, which allows for data to be returned in a SRS other than the native. 
Axis ordering¶

WFS 1.0.0 servers return geographic coordinates in longitude/latitude (x/y) order. This is the most common way to distribute data as well (for example, most shapefiles adopt this order by default).

However, the traditional axis order for geographic and cartographic systems is latitude/longitude (y/x), the opposite and WFS 1.1.0 specification respects this. This can cause difficulties when switching between servers with different WFS versions, or when upgading your WFS.

To sum up, the defaults are as follows:

WFS 1.1.0 request = latitude/longitude 
WMS 1.0.0 request = longitude/latitude 
GeoServer, however, in an attempt to minimize confusion and increase interoperability, has adopted the following conventions when specifying projections in the follow formats:

EPSG:xxxx - longitude/latitude 
http://www.opengis.net/gml/srs/epsg.xml#xxxx - longitude/latitude 
urn:x-ogc:def:crs:EPSG:xxxx - latitude/longitude 
WFS output formats¶

WFS returns features and feature information in a number of possible formats. This page shows a list of the output formats. In all cases the syntax for setting an output format is:

outputFormat=<outputformat>

where <outputformat> is any of the options below.

Note

Some additional output formats are available with the use of an extension, such as Excel. This list applies just to the basic GeoServer installation. The full list of output formats supported by your GeoServer instance can be found by requesting your WFS GetCapabilities.

Format
 Syntax
 Notes
 
GML2
 outputFormat=GML2
 Default option using WFS 1.0.0
 
GML3
 outputFormat=GML3
 Default option using WFS 1.1.0
 
Shapefile
 outputFormat=shape-zip
 Created in a ZIP archive
 
JSON
 outputFormat=json
  
 
CSV
 outputFormat=csv
  
 

  

WFS vendor parameters¶

WFS Vendor parameters are options that are not defined in the official WFS specification, but are allowed by it. GeoServer supports a range of custom WFS parameters.

CQL filters¶

When specifying a WFS GetFeature GET request, a filter can be specified in CQL (Common Query Language), as opposed to encoding the XML into the request. CQL sports a much more compact and human readable syntax compared to OGC filters. CQL isn’t as flexible as OGC filters, however, and can’t encode as many types of filters as the OGC specification does. In particular, filters by feature ID are not supported.

Example¶

A sample filter request using an OGC filter taken from a GET request:

filter=%3CFilter%20xmlns:gml=%22http://www.opengis.net/gml%22%3E%3CIntersects%3E%3CPropertyName%3Ethe_geom%3C/PropertyName%3E%3Cgml:Point%20srsName=%224326%22%3E%3Cgml:coordinates%3E-74.817265,40.5296504%3C/gml:coordinates%3E%3C/gml:Point%3E%3C/Intersects%3E%3C/Filter%3E

The same filter using CQL:

cql_filter=INTERSECT(the_geom,%20POINT%20(-74.817265%2040.5296504))

Reprojection¶

WFS 1.1 allows the ability to reproject data (to have GeoServer store the data in one projection and return GML in another).

GeoServer supports this using WFS 1.0 as well. When doing a WFS 1.0 GetFeature GET request you can add this parameter to specify the reprojection SRS:

srsName=<srsName>

where <srsName> is the code for the projection (such as EPSG:4326).

For POST requests, you can add the same code to the Query element.

XML request validation¶

By default, GeoServer is slightly more forgiving than the WFS specification requires. To force incoming XML requests to be strictly valid, use the following parameter:

strict=[true|false]

where false is the default option.

 

GetCapabilities namespace filter¶

WFS GetCapabilities requests can be filtered to only return layers corresponding to a particular namespace. To do this, add the following code to your request:

namespace=<namespace>

where <namespace> is the namespace prefix you wish to filter on.

Using an invalid namespace prefix will not cause any errors, but the document returned will contain no information on any layers.

Note

This only affects the capabilities document, and not any other requests. WFS requests given to other layers, even when a different namespace is specified, will still be processed.

Warning

Using this parameter may cause your capabilities document to become invalid (as the WFS specification requires the document to return at least one layer).

WFS reference¶

Introduction¶

The Web Feature Service (WFS) is a standard created by the OGC that refers to the sending and receiving of geospatial data through HTTP. WFS encodes and transfers information in Geography Markup Language, a subset of XML. The current version of WFS is 1.1.0. GeoServer supports both version 1.1.0 (the default since GeoServer 1.6.0) and version 1.0.0. There are differences between these two formats, some more subtle than others, and this will be noted where differences arise. The current version of WFS is 1.1. WFS version 1.0 is still used in places, and we will note where there are differences. However, the syntax will often remain the same.

An important distinction must be made between WFS and Web Map Service, which refers to the sending and receiving of geographic information after it has been rendered as a digital image.

Benefits of WFS¶

One can think of WFS as the “source code” to the maps that one would ordinarily view (via WMS). WFS leads to greater transparency and openness in mapping applications. Instead of merely being able to look at a picture of the map, as the provider wants the user to see, the power is in the hands of the user to determine how to visualize (style) the raw geographic and attribute data. The data can also be downloaded, further analyzed, and combined with other data. The transactional capabilities of WFS allow for collaborative mapping applications. In short, WFS is what enables open spatial data

Operations¶

WFS can perform the following operations:

Operation
 Description
 
GetCapabilities
 Retrieves a list of the server’s data, as well as valid WFS operations and parameters

获得服务器数据，执行操作
 
DescribeFeatureType
 Retrieves information and attributes about a particular dataset

获取数据集属性信息
 
GetFeature
 Retrieves the actual data, including geometry and attribute values

获得真实的数据，包括属性值
 
LockFeature
 Prevents a feature type from being edited

阻止数据被修改
 
Transaction
 Edits existing featuretypes by creating, updating, and deleting.

编辑数据
 
GetGMLObject
 (Version 1.1.0 only) - Retrieves element instances by traversing XLinks that refer to their XML IDs.
 

A WFS server that supports transactions is sometimes known as a WFS-T. GeoServer fully supports transactions.

GetCapabilities¶

The GetCapabilities operation is a request to a WFS server for a list of what operations and services (“capabilities”) are being offered by that server.

A typical GetCapabilities request would look like this (at URL http://www.example.com/wfs):

Using a GET request (standard HTTP):

http://www.example.com/wfs?

service=wfs&

version=1.1.0&

request=GetCapabilities

The equivalent using POST:

<GetCapabilities

service="WFS"

xmlns="http://www.opengis.net/wfs"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.opengis.net/wfs

http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"/>

GET requests are simplest to decode, so we will discuss them in detail, but the POST requests are analogous. (The actual requests would be all on one line, with no line breaks, but our convention here is to break lines for clarity.) Here there are three parameters being passed to our WFS server, service=wfs, version=1.1.0, and request=GetCapabilities. At a bare minimum, it is required that a WFS request have these three parameters (service, version, and request). GeoServer relaxes these requirements (setting the default version if omitted), but “officially” they are mandatory, so they should always be included. The service key tells the WFS server that a WFS request is forthcoming. The version key refers to which version of WFS is being requested. Note that there are only two version numbers officially supported: “1.0.0” and “1.1.0”. Supplying a value like “1” or “1.1” will likely return an error. The request key is where the actual GetCapabilities operation is specified.

 

The Capabilities document that is returned is a long and complex chunk of XML, but very important, and so it is worth taking a closer look. (The 1.0.0 Capabilities document is very different from the 1.1.0 document discussed here, so beware.) There are five main components we will be discussing (other components are beyond the scope of this document.):

ServiceIdentification
 This section contains basic “header” information such as the Name and ServiceType. The ServiceType mentions which version(s) of WFS are supported.
 
ServiceProvider
 This section provides contact information about the company behind the WFS server, including telephone, website, and email.
 
OperationsMetadata
 This section describes the operations that the WFS server recognizes and the parameters for each operation. A WFS server can be set up not to respond to all aforementioned operations.
 
FeatureTypeList
 This section lists the available featuretypes. They are listed in the form “namespace:featuretype”. Also, the default projection of the featuretype is listed here, along with the resultant bounding box for the data in that projection.
 
Filter_Capabilities
 This section lists filters available in which to request the data. SpatialOperators (Equals, Touches), ComparisonOperators (LessThan, GreaterThan), and other functions are all listed here. These filters are not defined in the Capabilities document, but most of them (like the ones mentioned here) are self-evident.
 

DescribeFeatureType¶

The purpose of the DescribeFeatureType is to request information about an individual featuretype before requesting the actual data. Specifically, DescribeFeatureType will request a list of features and attributes for the given featuretype, or list the featuretypes available.

Let’s say we want a list of featuretypes. The appropriate GET request would be:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=DescribeFeatureType

Note again the three required fields (service, version, and request). This will return the list of featuretypes, sorted by namespace.

If we wanted information about a specific featuretype, the GET request would be:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=DescribeFeatureType&

   typeName=namespace:featuretype

The only difference between the two requests is the addition of typeName=namespace:featuretype, where featuretype is the name of the featuretype and namespace is the name of the namespace that featuretype is contained in.

GetFeature¶

The GetFeature operation requests the actual spatial data. This is the “source code” spoken about previously. More so than the other operations, it is complex and powerful. Obviously, not all of its abilities will be discussed here.

The simplest way to run a GetFeature command is without any arguments.

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype

This syntax should be familiar from previous examples. The only difference is the request=GetFeature.

It is not recommended to run this command in a web browser, as this will return the geometries for all features in a featuretype. This can be a great deal of data. One way to limit the output is to specify a feature. In this case, the GET request would be:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   featureID=feature

Here there is the additional parameter of featureID=feature. Replace feature with the ID of the feature you wish to retrieve.

If the name of the feature is unknown, or if you wish to limit the amount of features returned, there is the maxFeatures parameter.

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   maxFeatures=N

In the above example, N is the number of features to return.

A question that may arise at this point is how the WFS server knows which N Features to return. The bad news is that it depends on the internal structure of the data, which may not be arranged in a very helpful way. The good news is that it is possible to sort the features based on an attribute, via the following syntax. (This is new as of 1.1.0.)

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   maxFeatures=N&

   sortBy=property

In the above example, sortBy=property determines the sort. Replace property with the attribute you wish to sort by. The default is to sort ascending. Some WFS servers require sort order to be specified, even if ascending. If so, append a +A to the request. To sort descending, add a +D to the request, like so:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   maxFeatures=N&

   sortBy=property+D

It is not necessary to to use sortBy with maxFeatures, but they can often complement each other.

To narrow the search not by feature, but instead by an attribute, use the propertyName key in the form propertyName=property. You can specify a single property, or multiple properties separated by commas. For a single property from all features, use the following:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   propertyName=property

For a single property from just one feature:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   featureID=feature&

   propertyName=property

Or more than one property from a feature:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   featureID=feature&

   propertyName=property1,property2

All of these permutations so far have centered around parameters of a non-spatial nature, but it is also possible to query for features based on geometry. While there are very limited tools available in a GET request for spatial queries (much more are available in POST requests using filters) one of the most important can be used. This is known as the “bounding box” or BBOX. The BBOX allows us to ask for only such features that are contained (or partially contained) inside a box of the coordinates we specify. The form of the bbox query is bbox=a1,b1,a2,b2``where ``a, b, c, and d refer to coordinates.

Notice that the syntax wasn’t bbox=x1,y1,x2,y2 or bbox=y1,x1,y2,x1. The reason the coordinate-free a,b syntax was used above is because the order depends on the coordinate system used. To specify the coordinate system, append srsName=CRS to the WFS request, where CRS is the coordinate reference system. As for which corners of the bounding box to specify (bottom left / top right or bottom right / top left), that appears to not matter, as long as the bottom is first. So the full request for returning features based on bounding box would look like this:

http://www.example.com/wfs?

   service=wfs&

   version=1.1.0&

   request=GetFeature&

   typeName=namespace:featuretype&

   bbox=a1,b1,a2,b2

Transaction¶

The Transaction operation performs edits of actual data that is exposed by the WFS. A transaction can add, modify and remove features. Each transaction consists of zero or more Insert, Update and Delete elements. Each element is performed in order. In GeoServer every transaction is ‘atomic’, meaning that if any of the elements fails then the data is left unchanged.

More information on the syntax of transactions can be found in the WFS specification, and in the GeoServer sample requests.

LockFeature¶

The LockFeature operation is theoretically useful in conjunction with transactions, so users can ‘lock’ an area of the map that they are editing, to ensure that other users don’t edit it. In practice no widely used clients support the LockFeature operation.

GetGMLObject¶

GetGMLObject is another operation that is little used in practical client applications. It only really makes sense in situations that require Complex Features. It allows clients to extract just a portion of the nested properties.