Specific GeoJSON validation JSON Schema for GeoJSON

Copyright © 2015 Open Geospatial Consortium. 35 ฀ The content of properties to a set of recognized list of attributes even if in JSON schema we cannot validate the inclusion of unknown properties. This is an example of a river collection JSON file: { id: river:ExampleRiverCollection, type: FeatureCollection, features: [ { id: wikipedia:Mississippi_River, type: Feature, geometry: { id: wikipedia:Mississippi_River, type: LineString, crs: ogc_def:crsOGC1.3CRS84, coordinates: [ [ -95.2075, 47.239722 ], [ -89.253333, 29.151111 ] ] }, properties: { url: wikipedia:Mississippi_River, type: riverType, name: mississipi, length: 3734, discharge: 16790, source: Lake Itasca , mouth: Gulf of Mexico, country: United States of America, bridges: [ Eads Bridge, Chain of Rocks Bridge ] } }, { id: wikipedia:Ebro, 36 Copyright © 2015 Open Geospatial Consortium. type: Feature, geometry: { id: wikipedia:Ebro, type: LineString, crs: ogc_def:crsOGC1.3CRS84, coordinates: [ [ -4.402942, 43.039111 ], [ 0.863056, 40.72 ] ] }, properties: { url: wikipedia:Ebro, type: riverType, name: ebro, length: 930, discharge: 426, source: Pico Tres Mares, mouth: Mediterranean Sea, country: Spain } } ] } This is how a JSON schema for validating this featureType looks: { schema: http:json-schema.orgdraft-04schema, title: Specific GeoJSON schema for riverType, type: object, required: [type], properties: { type: { enum: [ FeatureCollection] }, id: { type: string, Copyright © 2015 Open Geospatial Consortium. 37 format: uri }, bbox: { type: array, items: { type: array, minItems: 4, items: { type: number } } }, features: { type: array, items: { type: object, required: [ type, geometry,properties], properties: { type: {enum: [Feature]}, geometry: { ref: definitionsgeometry }, properties: { type: object, required: [type, name, country], properties: { url: { type: string, format: uri }, type: { enum: [riverType] }, name: { type: string}, length: { type: number}, discharge: { type: number}, source: { type: string}, mouth: { type: string}, country: { type: string}, bridges: { type: array, items: { type: string } } } } } } } }, definitions: { 38 Copyright © 2015 Open Geospatial Consortium. geometry: { title: geometry, type: object, properties: { type: { enum: [ LineString ] }, coordinates: { type: array, minItems: 2, items: { type: array, minItems: 2, items: { type: number } } } } } } } Recommendation 12: Adopt the creation of specific JSON schema documents as a means of defining feature types and as a means for feature instance validation as the equivalent of GML application schema. Target: WFS and OAB NOTE: the adoption of this strategy will give GeoJSON implementations more robustness. It is particularly important to increase interoperability of the services that has to process data.

7.2 GeoJSON in JSON-LD

JSON-LD provides a transformation template called “context” that indirectly defines a set of rules or transforming a JSON file into an RDF. This is similar to writing a XSLT but using a complete different language. In this section we describe how to convert the previous GeoJSON example into a useful JSON-LD. To do so, there are 3 main issues: Copyright © 2015 Open Geospatial Consortium. 39 _ Create the right “context” code to give semantics to the “key names”. _ Remove the “properties” node. _ Express the coordinates correctly in RDF. To solve the first issue, we use a subset of the experimental vocabulary that is found in http:geojson.orgvocab that sometimes uses the URI http:example.comvocab and some other the http:ld.geojson.orgvocab that is supposed to contain the GeoJSON concepts. In fact the complete vocabulary can be found at http:geojson.orgcontextsgeojson-base.jsonld. Our subset contains geojson:coordinates, geojson:Feature and geojson:LineString. We also used the URI http:www.opengis.uab.catRiver to define the semantics of the river properties To solve the second I had to apply a little “trick” using the same “id” for the root object, the geometry object and the properties object and associate “geometry” and “properties” to the “_:”void uri. GeoJSON is very clear about the encoding of the coordinates. Coordinates are n- dimensional arrays of numbers. Unfortunately sorted n-dimensional arrays cannot be exported to RDF. By default, in JSON-LD, the elements of an array are considered an “unsorted” list of values, so that they become unsorted in the RDF transformation. JSON- LD provides a methodology to transform a sorted array using “container”: “list”, but, unfortunately the implementations we have tested, only make it possible for one dimensional array. In fact, this issue is discussed in https:github.comgeojsongeojson- ldissues28 and with less completeness in https:github.comgeojsongeojson- ldissues26 and https:github.comgeojsongeojson-ldissues12 that were closed with no solution. In conclusions, the current GeoJSON encoding for coordinates prevents the correct automatic transformation to RDF via JSON-LD. Recommendation 13: Consider carefully the unsolved issue where GeoJSON coordinates prevents a natural way to apply JSON-LD to GeoJSON and an automatic conversion to RDF. Following