Our typing of the top-level GeoJSON object is currently very strict, requiring that the type and features keys, and only those keys, are defined. Real-world GeoJSON files often have additional top-level keys, such as crs (to specify an alternative coordinate system), bounds or bbox for the extent of the dataset, name to create a named layer, and so on.
To my knowledge, we don't really care whether there is additional information at that top level. At most, we may want to set restrictions on certain optional keys. For example, we do want the crs to have a value of WGS84, if it's defined.
This is a list of (currently) suggested changes (and whether they have been implemented):
[ ] If crs is defined at the top level, require that it refer to WGS84. It may be difficult to set this requirement through jsonschema, but we could at least support an enum that includes { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }.
Our typing of the top-level GeoJSON object is currently very strict, requiring that the
typeandfeatureskeys, and only those keys, are defined. Real-world GeoJSON files often have additional top-level keys, such ascrs(to specify an alternative coordinate system),boundsorbboxfor the extent of the dataset,nameto create a named layer, and so on.To my knowledge, we don't really care whether there is additional information at that top level. At most, we may want to set restrictions on certain optional keys. For example, we do want the
crsto have a value of WGS84, if it's defined.This is a list of (currently) suggested changes (and whether they have been implemented):
crsis defined at the top level, require that it refer to WGS84. It may be difficult to set this requirement through jsonschema, but we could at least support an enum that includes{ "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }.