16
Copyright © 2013 Open Geospatial Consortium.
Example fixed unit:
width:19.29426795
The other option would be to add an additional property for the unit: Example variable unit:
width:19.29426795, width_unit:m
The second option is more general, but avoiding unit conversions in clients by fixing the unit and requiring that the conversion, if necessary, is done on the server side may also
be a benefit. We will therefore follow the fixed unit approach.
6.2.3.8 String properties with regular expression patterns
In this case, the question is rather how this will be represented in the UML model. In OWS-78 regular expression patterns have been expressed in an OCL constraint using the
syntax property.matchesregex.
Originally, the assumption was that we would ignore such constraints in the JSON encoding rule as there is no JSON equivalent for Schematron. However, JSON Schema
supports specifying patterns on string properties using the regular expression pattern in the ECMA 262Perl 5 format which includes – according to current knowledge – the
patterns supported by XPath 2.0.
6.2.3.9 Properties with values that are featuresobjects
Extended: Value of the JSON property is a URI identifying the object. It is assumed that the URI can be dereferenced and provides a representation of the object.
Example:
owner:http:example.comPerson123
Simple: In GeoJSON a URI will be used, too. In the GeoServices REST API, relationships to other objects are documented separate
from the schema using joins. The objects will contain properties that represent foreign and primary keys.
Example:
owner:123
Here, 123 is the foreign key that references a Person object with the objectId 123. For cases, when the URI scheme of the server where the data will be deployed is known
at schema creation time, we can also encode the relationship in the schema. An example:
Copyright © 2013 Open Geospatial Consortium.
17 Assume we have feature types BuildingGeopoint and Person and they would be available
at http:example.comTDSFeatureServer1{objectId}?f=json and http:example.comTDSFeatureServer2{objectId}?f=json respectively. Then the link to
the owner could be expressed using the link concept in JSON schema shown below. Of course, that requires that the URI scheme is known at the time the schema is created. If
this is acceptable, then we could perhaps think of a way in which to encode this information also in the simple encoding rule.
{ schema:http:json-schema.orgdraft-03schema,
id:http:example.comschematdsBuildingGeopoint.json, title:Building feature with point geometry,
type:object, properties:{
entityType:{ type:string,
title:type of the feature type, enum:[
BuildingGeopoint ]
}, geometry:{
title:feature geometry, ref:http:schemas.opengis.netgsr1.0point.json
}, attributes:{
title:featureobject attributes, type:object,
properties:{ objectId:{
type:integer, description:Object identifier,
required:true },
owner:{ description:Owner of the buidling,
type:integer }
} },
links:[ {
rel:related, href:http:example.comTDSFeatureServer2{attributesowner}?f=json
} ]
} }
6.2.3.10 Multiple geometry properties per feature
The restriction to one geometry is a limitation of both GeoServices JSON and GeoJSON and is very much part of the foundation of these feature representations as expressed by
the specific geometry property, separate from the rest of the feature properties. Therefore, the two obvious options to allow for additional geometry properties
additional geometry properties as part of the attributeproperties object or additional geometry properties like geometry-2 etc. do seem to go against the basic concepts of
these JSON encodings.
