Copyright © 2015 Open Geospatial Consortium.
87
topLeftCorner: POINT-20037508.3427892, 20037508.3427892,
tileWidth: 256, tileHeight: 256,
matrixWidth: 2, matrixHeight: 2
},{ id: wmtss:WorldWebMercatorQuad18,
type: wmts:TileMatrix, scaleDenominator: 2132.729583849784,
topLeftCorner: POINT-20037508.3427892, 20037508.3427892,
tileWidth: 256, tileHeight: 256,
matrixWidth: 262272, matrixHeight: 262272
} ] }]
}
Recommendation 30: Include in the WMTS Simple profile the JSON description of the WMTS simple two tile matrix sets.
Target: WMS.SWG
10.4 Serving GeoJSON with a Web Feature Service
Some people believe that WFS can only serve GML features but even if this is a common case nothing in the standard prevents from using other geospatial formats and encodings.
In particular, it is possible to server GeoJSON as a result of a WFS GetFeature request. In fact, GeoServer has been doing this for a quite a while. A more profound question is if it
possible to have a WFS without GML support. WFS is deeply related with the idea of the GML application schema and the definition of feature types. We already have mentioned
that GeoJSON does not provide this concept directly. Reintroducing this concept in GeoJSON as an extension is easy by means of adding to each GeoJSON feature a
property called “type”. This will allow a WFS server to group the features in feature types and to provide a list of available feature types in the GetCapabilities.
Recommendation 31: For a WFS serving GeoJSON, force the features to have a property that contains the feature type.
Target: WFS.SWG
A fundamental question could be the format that a DescribeFeatureType operation has to return when asking the characteristics of a feature type. Having to return a GML
encoding seems unnecessary. One possibility explored is to return a encoding neutral representation for describing feature types as described in ISO19110. Following the new
ISO19115-3 encoding for metadata a river object can be encoded like this:
gfc:FC_FeatureCatalogue gfc:featureType
gfc:FC_FeatureType gfc:typeNameriverTypegfc:typeName
88
Copyright © 2015 Open Geospatial Consortium.
gfc:isAbstract gco:Booleanfalsegco:Boolean
gfc:isAbstract gfc:carrierOfCharacteristics
gfc:FC_FeatureAttribute gfc:memberName length gfc:memberName
gfc:definitiongco:CharacterStringLength gco:CharacterStringgfc:definition
gfc:cardinality1gfc:cardinality gfc:codegco:CharacterStringlength
gco:CharacterStringgfc:code gfc:valueMeasurementUnitm
gfc:valueMeasurementUnit gfc:FC_FeatureAttribute
gfc:carrierOfCharacteristics gfc:FC_FeatureType
gfc:featureType gfc:FC_FeatureCatalogue
It could be preferable to be able use a JSON encoding also for this aspect. There is always the possibility to generate a JSON encoding for ISO19110 but it could be better to
adopt a solution that already exists. We have already discussed in this ER some of the current alternatives for GeoJSON validation in subclause 7 that could be used here. We
have explored the possibility to create specific JSON schema for each feature type and also to use JSON-LD “context” section to achieve a similar functionality. We have
seen that JSON-LD is an approved standard and also allows a nice connection to RDF representations of features. The connection to RDF and the semantic web is particularly
attractive giving the use of GeoJSON and extra characteristic that GML cannot provide as easily.
Recommendation 32: Consider that WFS DescribeFeatureType returns a context section describing the Feature type in GeoJSON.
Target: WFS.SWG
10.4.1 Pointers to GeoJSON fragments
One of the issues that we have in using GeoJSON for describing features is that WFS uses FES, and FES needs XPath:
fes:PropertyIsLessThanOrEqualTo fes:ValueReference
myns:Personmyns:mailAddress myns:Addressmyns:streetNumber
fes:ValueReference fes:Literal10999fes:Literal
fes:PropertyIsLessThanOrEqualTo
Currently, JSON provides 2 alternatives to do this: JSON Pointer https:tools.ietf.orghtmlrfc6901 and JSON Path http:goessner.netarticlesJsonPath.
