CityJSON Specifications 1.0.0

Living Standard,

This version:
https://cityjson.org/specs/1.0.0/
Latest published version:
https://cityjson.org/specs/
Issue Tracking:
GitHub
Editor:
Hugo Ledoux (TU Delft)

Abstract

CityJSON is a JSON-based encoding for a subset of the OGC CityGML data model (version 2.0.0). It defines how to store digital 3D models of cities and landscapes. The aim of CityJSON is to offer an alternative to the GML encoding of CityGML, which can be verbose and complex (and thus rather frustrating to work with). CityJSON aims at being easy-to-use, both for reading datasets, and for creating them. It was designed with programmers in mind, so that tools and APIs supporting it can be quickly built.

1. CityJSON Object

A CityJSON object represents one 3D city model of a given area, this model may contain features of different types, as defined in the CityGML data model.

The minimal valid CityJSON object is thus:

{
  "type": "CityJSON",
  "version": "1.0",
  "CityObjects": {},
  "vertices": []
}

An "empty" CityJSON will look like this:

{
  "type": "CityJSON",
  "version": "1.0",
  "extensions": {},
  "metadata": {},
  "transform": {
    "scale": [],
    "translate": []
  },
  "CityObjects": {},
  "vertices": [],
  "appearance": {},
  "geometry-templates": {}
}
While the order of the member values of a CityJSON should preferably be as above, not all JSON generators allow one to do this, thus the order is not prescribed.

2. City Object types

A City Object is a JSON object for which the type member’s value is one of the following (of type string):

1st-level 2nd-level
"Building" "BuildingPart", "BuildingInstallation"
"Bridge" "BridgePart", "BridgeInstallation", "BridgeConstructionElement"
"CityObjectGroup"
"CityFurniture"
"GenericCityObject"
"LandUse"
"PlantCover"
"Railway"
"Road"
"SolitaryVegetationObject"
"TINRelief"
"TransportSquare"
"Tunnel" "TunnelPart", "TunnelInstallation"
"WaterBody"

There are 2 kinds of City Objects, this is because the schema of CityGML has been flattened out. Both types are represented as a City Object in a CityJSON Object.

  1. 1st-level: City Objects that can "exist by themselves".

  2. 2nd-level: City Objects that need to have a "parents" to exist.

For example, a "BuildingInstallation" cannot be present in a dataset without being the "children" of a "Building", but a "Building" can be present by itself.

A City Object:

"CityObjects": {
  "id-1": {
    "type": "Building",
    "geographicalExtent": [ 84710.1, 446846.0, -5.3, 84757.1, 446944.0, 40.9 ], 
    "attributes": { 
      "measuredHeight": 22.3,
      "roofType": "gable",
      "owner": "Elvis Presley"
    },
    "children": ["id-2"],
    "geometry": [{...}]
  },
  "id-2": {
    "type": "BuildingPart", 
    "parents": ["id-1"],
    ...
  },
  "id-3": {
    "type": "BuildingInstallation", 
    "parents": ["id-1"],
    ...
  },
  "id-4": {
    "type": "LandUse", 
    ...
  }
}

2.1. Attributes

The attributes prescribed by CityGML differ per City Object, and can be seen either in the official CityGML documentation or in the schemas of CityJSON.

In CityJSON, any other attributes not prescribed by the CityGML data model can be added with a JSON key-value pair ("owner" in the example above is one such attribute) in the "attributes" of a City Object.

All the City Objects have the following 3 possible attributes:

  1. "class"

  2. "function"

  3. "usage"

While CityGML does not prescribe the values for these, the SIG 3D maintains a codelist that can be used. In CityJSON, as can be seen in the schemas, the values should be a string, thus either the name of the values should be used, or the code as a string:

"CityObjects": {
  "id-1": {
    "type": "LandUse", 
    "attributes": { 
      "function": "Industry and Business"
    },
    "geometry": [{...}]
  },
  "id-2": {
    "type": "WaterBody", 
    "attributes": { 
      "class": "1010"
    },
    "geometry": [{...}]
  }
}

2.2. Building

Three City Objects are related to buildings: "Building", "BuildingPart", and "BuildingInstallation".

The geometry of both "Building" and "BuildingPart" can only be represented with these Geometry Objects: (1) "Solid", (2) "CompositeSolid", (3) "MultiSurface".

The geometry of a "BuildingInstallation" object can be represented with any of the Geometry Objects.

A City Object of type "Building" or "BuildingPart" may have a member "address", whose value is a JSON object describing the address. One location (a "MultiPoint") can be given, for instance to position the front door inside the building.

"CityObjects": {
  "id-1": {
    "type": "Building", 
    "attributes": { 
      "roofType": "gable"
    },
    "geographicalExtent": [ 84710.1, 446846.0, -5.3, 84757.1, 446944.0, 40.9 ],
    "children": ["id-56", "id-832", "mybalcony"]
  },
  "id-56": {
    "type": "BuildingPart", 
    "parents": ["id-1"],
    ...
  },
  "mybalcony": {
    "type": "BuildingInstallation", 
    "parents": ["id-1"],
    ...
  }
}
{
  "type": "Building", 
  "address": {
    "CountryName": "Canada",
    "LocalityName": "Chibougamau",
    "ThoroughfareNumber": "1",
    "ThoroughfareName": "rue de la Patate",
    "PostalCode": "H0H 0H0"
  },
}

2.3. Transportation

CityJSON uses 3 classes related to transportation ("Road", "Railway", "TransportSquare") and omits the "Track" from CityGML because it simply can be a road with specific attributes. "TransportSquare" is used to model for instance parking lots and squares.

In CityGML, each of the 3 classes can have a number of "TrafficArea" and "AuxiliaryTrafficArea", which are defined as new surfaces. In CityJSON, these surfaces do not need to be defined again since the road surfaces become Semantic Surface Objects (with type "TrafficArea" or "AuxiliaryTrafficArea"). That is, the surface representing a road should be split into sub-surfaces (therefore forming a "MultiSurface" or a "CompositeSurface"), and each of the sub-surfaces get a semantics attached to it.

The geometry of a City Object of type "Road", "Railway", "TransportSquare" can be of types "MultiSurface", "CompositeSurface" or "MultiLineString".

"ma_rue": {
  "type": "Road", 
  "geometry": [{
    "type": "MultiSurface",
    "lod": 2,
    "boundaries": [
       [[0, 3, 2, 1, 4]], [[4, 5, 6, 666, 12]], [[0, 1, 5]], [[20, 21, 75]]
    ]
  }],
  "semantics": {
    "surfaces": [
      {
        "type": "TrafficArea",
        "surfaceMaterial": ["asphalt"],
        "function": "road"
      },
      {
        "type": "AuxiliaryTrafficArea",
        "function": "green areas"
      },
      {
        "type": "TrafficArea",
        "surfaceMaterial": ["dirt"],
        "function": "road"
      }
    ],
    "values": [0, 1, null, 2]
  }
}

2.4. TINRelief

The geometry of a City Object of type "TINRelief" can only be of type "CompositeSurface".

CityJSON does not define a specific Geometry Object for a TIN (triangulated irregular network), it is simply a CompositeSurface for which every surface is a triangle (thus a polygon having 3 vertices, and no interior ring).

"myterrain01": {
  "type": "TINRelief", 
  "geographicalExtent": [ 84710.1, 446846.0, -5.3, 84757.1, 446944.0, 40.9 ],
  "geometry": [{
    "type": "CompositeSurface",
    "lod": 2,
    "boundaries": [
       [[0, 3, 2]], [[4, 5, 6]], [[0, 1, 5]], [[1, 2, 6]], [[2, 3, 7]], [[3, 0, 4]]
    ]
  }]    
}

2.5. WaterBody

The geometry of a City Object of type "WaterBody" can be of types: "MultiLineString", "MultiSurface", "CompositeSurface", "Solid", or "CompositeSolid".

"mygreatlake": {
  "type": "WaterBody", 
  "attributes": {
    "usage": "leisure",
  },
  "geometry": [{
    "type": "Solid",
    "lod": 2,
    "boundaries": [
      [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]] ]
    ]
  }]    
}               

2.6. LandUse

The geometry of a City Object of type "LandUse" can be of type "MultiSurface" or "CompositeSurface".

"oneparcel": {
  "type": "LandUse", 
  "geometry": [{
    "type": "MultiSurface",
    "lod": 1,
    "boundaries": [
      [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]]
    ]
  }]    
}

2.7. PlantCover

The geometry of a City Object of type "PlantCover" can be of type "MultiSurface" or "MultiSolid".

"plants": {
  "type": "PlantCover", 
  "attributes": { 
    "averageHeight": 11.05
  },
  "geometry": [{
    "type": "MultiSolid",
    "lod": 2,
    "boundaries": [
      [
        [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[10, 13, 22, 31]] ]
      ],
      [
        [ [[5, 34, 31, 12]], [[44, 54, 62, 74]], [[10, 111, 445, 222]], [[111, 123, 922, 66]] ]
      ]  
    ]
  }]    
}

2.8. SolitaryVegetationObject

The geometry of a City Object of type "SolitaryVegetationObject" can be any of the following: "MultiPoint", "MultiLineString", "MultiSurface", "CompositeSurface", "Solid", or "CompositeSolid".

"onebigtree": {
  "type": "SolitaryVegetationObject", 
  "attributes": { 
    "trunkDiameter": 5.3,
    "crownDiameter": 11.0
  },
  "geometry": [{
    "type": "MultiPoint",
    "lod": 0,
    "boundaries": [1]
  }]
}

2.9. CityFurniture

The geometry of a City Object of type "CityFurniture" can be any of the following: "MultiPoint", "MultiLineString", "MultiSurface", "CompositeSurface", "Solid", or "CompositeSolid".

"stop": {
  "type": "CityFurniture", 
  "attributes": { 
    "function": "bus stop"
  },
  "geometry": [{
    "type": "MultiSurface",
    "lod": 2,
    "boundaries": [
      [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]]
    ]
  }]
}

2.10. GenericCityObject

The geometry of a City Object of type "GenericCityObject" can be any of the following: "MultiPoint", "MultiLineString", "MultiSurface", "CompositeSurface", "Solid", or "CompositeSolid".

"whatisthat": {
  "type": "GenericCityObject", 
  "attributes": { 
    "usage": "it’s not clear"
  },
  "geometry": [{
    "type": "CompositeSurface",
    "lod": 1,
    "boundaries": [
      [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]]
    ]
  }]
}

2.11. Bridge

Four City Objects are related to bridges: "Bridge", "BridgePart", "BridgeInstallation", and "BridgeConstructionElement".

The geometry of both "Bridge" and "BridgePart" can only be represented with these Geometry Objects: (1) "Solid", (2) "CompositeSolid", (3) "MultiSurface".

The geometry of a "BridgeInstallation" or "BridgeConstructionElement" object can be represented with any of the Geometry Objects.

A City Object of type "Bridge" or "BridgePart" may have a member "address", whose value is a JSON object describing the address. One location (a "MultiPoint") can be given, for instance to locate the front door inside the building.

"CityObjects": {
  "LondonTower": {
    "type": "Bridge", 
    "address": {
      "CountryName": "UK",
      "LocalityName": "London"
    },
    "children": ["Bext1", "Bext2", "Inst-2017-11-14"],
    "geometry": [{
      "type": "MultiSurface",
      "lod": 2,
      "boundaries": [
        [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]], [[2, 3, 7, 6]], [[3, 0, 4, 7]]
      ]
    }]    
  }
}

2.12. Tunnel

Three City Objects are related to tunnels: "Tunnel", "TunnelPart", and "TunnelInstallation".

The geometry of both "Tunnel" and "TunnelPart" can only be represented with these Geometry Objects: (1) "Solid", (2) "CompositeSolid", (3) "MultiSurface".

The geometry of a "TunnelInstallation" object can be represented with any of the Geometry Objects.

"CityObjects": {
  "Lærdalstunnelen": {
    "type": "Tunnel", 
    "attributes": { 
      "yearOfConstruction": 2000,
      "length": "24.5km"
    },
    "children": ["stoparea1"],
    "geometry": [{
      "type": "Solid",
      "lod": 2,
      "boundaries": [
        [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]] ]
      ]
    }] 
  }
}

2.13. CityObjectGroup

The CityGML concept of groups, where City Objects are aggregated based on certain criteria (think of a neighbourhood for instance), is possible in CityJSON. As in CityGML, the group is a City Object, and it can contain, if needed, a geometry (the polygon representing the neighbourhood for instance).

A City Object of type "CityObjectGroup" must have a member "members", whose value is an array of the IDs of the City Objects that the group contains. Since a "CityObjectGroup" is also a City Object, it can be part of another group.

As for other City Objects, a City Object of type "CityObjectGroup" may have a member "geometry", although only one geometry is allowed in the array of geometries.

"CityObjects": {
  "my-neighbourhood": {
    "type": "CityObjectGroup",
    "members": ["building1", "building2"],
    "geometry": [{
      "type": "MultiSurface",
      "lod": 2,
      "boundaries": [ [[2, 4, 5]] ]
    }]
  }
}

3. Geometry Objects

CityJSON defines the following 3D geometric primitives, all of them are embedded in 3D space (and therefore their vertices have (x, y, z) coordinates). The indexing mechanism of the format Wavefront OBJ is reused, that is a geometry does not store the locations of its vertices, but points to a vertex in a list (property "vertices" in the CityJSON Object).

As is the case in CityGML, only linear and planar primitives are allowed; no curves or parametric surfaces can be represented.

A Geometry object is a JSON object for which the type member’s value is one of the following:

  1. "MultiPoint"

  2. "MultiLineString"

  3. "MultiSurface"

  4. "CompositeSurface"

  5. "Solid"

  6. "MultiSolid"

  7. "CompositeSolid"

A Geometry object:

There is no Geometry Object for MultiGeometry. Instead, for the "geometry" member of a CityObject, the different geometries may be enumerated in the array (all with the same value for the member "lod").

3.1. The coordinates of the vertices

A CityJSON must have one member named "vertices", whose value is an array of coordinates of each vertex of the city model. Their position in this array (0-based) is used to represent the Geometric Objects.

"vertices": [
  [0.0, 0.0, 0.0],
  [1.0, 0.0, 0.0],
  [0.0, 0.0, 0.0],
  ...
  [1.0, 0.0, 0.0],
  [8523.134, 487625.134, 2.03]
]

3.2. Arrays to represent boundaries

JSON does not allow comments, the comments in the example below (C++ style: //-- my comments) are only to explain the cases, and should be removed.
{
  "type": "MultiPoint",
  "lod": 1,
  "boundaries": [2, 44, 0, 7]
}
{
  "type": "MultiLineString",
  "lod": 1,
  "boundaries": [
    [2, 3, 5], [77, 55, 212]
  ]  
}
{
  "type": "MultiSurface",
  "lod": 2,
  "boundaries": [
    [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]]
  ]
}
{
  "type": "Solid",
  "lod": 2,
  "boundaries": [
    [ [[0, 3, 2, 1, 22]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]] ], //-- exterior shell
    [ [[240, 243, 124]], [[244, 246, 724]], [[34, 414, 45]], [[111, 246, 5]] ] //-- interior shell
  ]
}
{
  "type": "CompositeSolid",
  "lod": 3,
  "boundaries": [
    [ //-- 1st Solid
      [ [[0, 3, 2, 1, 22]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]] ],
      [ [[240, 243, 124]], [[244, 246, 724]], [[34, 414, 45]], [[111, 246, 5]] ]
    ],
    [ //-- 2st Solid
      [ [[666, 667, 668]], [[74, 75, 76]], [[880, 881, 885]], [[111, 122, 226]] ] 
    ]    
  ]
}

3.3. Semantic Surface Object

A Semantics Surface is a JSON object representing the semantics of a surface, and may also represent other attributes of the surface (eg the slope of the roof or the solar potential).

A Semantic Object:

{
  "type": "RoofSurface",
  "slope": 16.4,
  "children": [2, 37],
  "solar-potential": 5
}

{
  "type": "Window",
  "parent": 2,
  "type-glass": "HR++"
}

"Building", "BuildingPart", and "BuildingInstallation" can have the following semantics for (LoD0 to LoD3; LoD4 is omitted):

For "WaterBody":

For Transportation ("Road", "Railway", "TransportSquare"):

Because in one given City Object (say a "Building") several surfaces can have the same semantics (think of a complex building that has been triangulated, there can be dozens of triangles used to model the same surface), a Semantic Surfaces object has to be declared once, and each of the surfaces used to represent it points to it. This is achieved by first declaring all the Semantic Surfaces in an array, and then having an array where each surface links to Semantic Surfaces (position in the array).

A Geometry object:

{
  "type": "MultiSurface",
  "lod": 2,
  "boundaries": [
    [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[0, 2, 3, 8]], [[10, 12, 23, 48]]
  ],
  "semantics": {
    "surfaces" : [
      {
        "type": "WallSurface",
        "slope": 33.4,
        "children": [2]
      }, 
      {
        "type": "RoofSurface",
        "slope": 66.6
      },
      {
        "type": "Door",
        "parent": 0,
        "colour": "blue"
      }
    ],
    "values": [0, 0, null, 1, 2]
  }
}
A null value is used to specify that a given surface has no semantics, but to avoid having arrays filled with null, it is also possible to specify null for a shell or a whole Solid in a MultiSolid, the null propagates to the nested arrays.
{
   "type": "CompositeSolid",
   "lod": 2,
   "boundaries": [
     [ //-- 1st Solid
       [ [[0, 3, 2, 1, 22]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]] ]
     ],
     [ //-- 2nd Solid
       [ [[666, 667, 668]], [[74, 75, 76]], [[880, 881, 885]], [[111, 122, 226]] ] 
     ]    
   ],
   "semantics": {
     "surfaces" : [
       {      
         "type": "RoofSurface",
       }, 
       {
         "type": "WallSurface",
       }
     ],
     "values": [
       [ //-- 1st Solid
         [0, 1, 1, null]
       ],
       [ //-- 2nd Solid get all null values
         null
       ]
     ]
   }
 }  

4. Metadata

The metadata related to the 3D city model may be stored in a JSON object that may have different members, as follows. Many of the members in ISO19115 are used, and a few are added because they are useful in 3D in a city modelling context (eg "presentLoDs" and "thematicModels"). To see all the possible ones, look at the schema file metadata.schema.json of a given version.

"metadata": {
  "datasetTitle": "3D city model of Chibougamau, Canada",
  "datasetReferenceDate": "1977-02-28",
  "geographicLocation": "Chibougamau, Québec, Canada",
  "referenceSystem": "urn:ogc:def:crs:EPSG::2355",
  "geographicalExtent": [ 84710, 346846, 5, 84757, 346944, 40 ],
  "datasetPointOfContact": {
    "contactName": "3D Geoinformation Group",
    "phone": "+31-6666666666",
    "address": "Delft University of Technology, the Netherlands",
    "emailAddress": "elvis@tudelft.nl",
    "contactType": "organization",
    "website": "https://3d.bk.tudelft.nl"
  },
  "metadataStandard": "ISO 19115 - Geographic Information - Metadata",
  "metadataStandardVersion": "ISO 19115:2014(E)"
}

4.1. CRS

The coordinate reference system (CRS) may be given as a string. OGC CRS URNs such as "urn:ogc:def:crs:EPSG::7415" are favoured over the legacy ones such as "EPSG:7415":

For instance, for the Dutch national CRS in 3D:

"metadata": {
  "referenceSystem": "urn:ogc:def:crs:EPSG::7415"
}

Be aware that the CRS should be a three-dimensional one, ie the elevation/height values should be with respect to a specific datum.

Unlike in (City)GML where each object can have a different CRS (eg a wall of a building could theoretically have a different from the other walls used to represent the building), in CityJSON all the city objects need to be in the same CRS.

4.2. Geographic Extent (bbox)

While this can be extracted from the dataset itself, it is useful to store it. It may be stored as an array with 6 values: [minx, miny, minz, maxx, maxy, maxz]

"metadata": {
  "geographicalExtent": [ 84710.1, 446846.0, -5.3, 84757.1, 446944.0, 40.9 ]
}

4.3. Geographic location

The name of an area or a city.

"metadata": {
  "geographicLocation": "Chibougamau, Québec, Canada"
}

4.4. Topic Category

A one-word category, the possible values are enumerated in the Table B.3.30 of the ISO19115-1:2014 document

"metadata": {
  "datasetTopicCategory": "planningCadastre"
}

4.5. Lineage

It is possible to give the lineage of one or more city objects in the datasets. This allows us to document how certain city objects were reconstructed; if many were with the same method then their IDs should simply be listed in "featureID".

"lineage": [
   {
     "featureIDs": ["id-1", "id-2", "id-8235"],
     "source": {
       "description": "Source of Terrain Data",
          "sourceSpatialResolution": "10 points/m2",
          "sourceReferenceSystem": "urn:ogc:def:crs:EPSG::4326"
     },
     "processStep": {
       "description" : "Processing of Terrain Data using 3dfier",
       "processor": {
         "contactName": "3D Geoinformation Group",
     "phone": "+31-6666666666",
       "address": "Delft University of Technology, the Netherlands",
       "emailAddress": "3d.bk@tudelft.nl",
       "contactType": "organization",
       "website": "https://3d.bk.tudelft.nl"
       }
     }
   }
 ]
It should be noticed that JSON does not have a date type, and thus the representations defined by RFC 3339, Section 5.6 should be used. A simple date is "full-date" (thus "1977-07-11" as a string), and should be used for the metadata above.

It’s also possible, for other attributes in a CityJSON file, to have a date with a time is a "full-time" (thus "1985-04-12T23:20:50.52Z" as a string).

5. Transform Object

To reduce the size of a file, it is possible to represent the coordinates of the vertices with integer values, and store the scale factor and the translation needed to obtain the original coordinates (stored with floats/doubles). To use compression, a CityJSON object may have one member "transform", whose values are 2 mandatory JSON objects ("scale" and "translate"), both arrays with 3 values.

The scheme of TopoJSON (called quantization) is reused, and here we simply add a third coordinate because our vertices are embedded in 3D space.

If a CityJSON object has a member "transform", to obtain the real position of a given vertex v, we must take the 3 values vi listed in the "vertices" member and:

v[0] = (vi[0] * ["transform"]["scale"][0]) + ["transform"]["translate"][0]
v[1] = (vi[1] * ["transform"]["scale"][1]) + ["transform"]["translate"][1]
v[2] = (vi[2] * ["transform"]["scale"][2]) + ["transform"]["translate"][2]

If the CityJSON file does not have a "transform" member, then the values of the vertices must be read as-is.

"transform": {
    "scale": [0.01, 0.01, 0.01],
    "translate": [4424648.79, 5482614.69, 310.19]
}

6. Geometry templates

CityGML’s Implicit Geometries, better known in computer graphics as templates, are one method to compress files since the geometries (eg benches, lamp posts, and trees), need only be defined once. In CityJSON, they are implemented slightly different from in CityGML: they are defined separately in the file, and each template can be reused. (While in CityGML one reuses the geometry used for another City Object.)

The Geometry Templates are defined as a JSON object that:

"geometry-templates": {
  "templates": [
    {
      "type": "MultiSurface",
      "lod": 2,
      "boundaries": [ 
         [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]]
      ]
    },
    {
      "type": "MultiSurface",
      "lod": 1,
      "boundaries": [ 
         [[1, 2, 6, 5]], [[2, 3, 7, 6]], [[3, 0, 4, 7]]
      ]
    }
  ],
  "vertices-templates": [
    [0.0, 0.5, 0.0],
    ...
    [1.0, 1.0, 0.0],
    [0.0, 1.0, 0.0]
  ]
}

A given template can be used for a City Object instead of a Geometry Object. A new JSON object of type "GeometryInstance" is defined, and it:

{
  "type": "SolitaryVegetationObject", 
  "geometry": [
    {
      "type": "GeometryInstance",
      "template": 0,
      "boundaries": [372]
      "transformationMatrix": [
        2.0, 0.0, 0.0, 0.0,
        0.0, 2.0, 0.0, 0.0,
        0.0, 0.0, 2.0, 0.0,
        0.0, 0.0, 0.0, 1.0
      ]
    }
  ]
}

7. Appearance Object

Both textures and materials are supported, and the same mechanisms used in CityGML are reused, so the conversion back-and-forth is easy. The material is represented with the X3D specifications, as is the case for CityGML. For the texture, the COLLADA is reused, as is the case for CityGML. However:

An Appearance Object is a JSON object that

"appearance": {
  "materials": [],
  "textures":[],
  "vertices-texture": [],
  "default-theme-texture": "myDefaultTheme1",
  "default-theme-material": "myDefaultTheme2"
}

7.1. Geometry Object having material(s)

Each surface in a Geometry Object can have one or more materials assigned to it. To store these, a Geometry Object may have a member "material", the value of this member is a collection of key-value pairs, where the key is the theme of the material, and the value is one JSON object that must contain either:

In the following, the Solid has 4 surfaces, and there are 2 themes: "irradiation" and "irradiation-2" could for instance represent different colours based on different scenarios of an solar irradiation analysis. Notice that the last surface get no material (for both themes), thus null is used.

{
  "type": "Solid",
  "lod": 2,
  "boundaries": [
    [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]] ] 
  ],
  "material": {
    "irradiation": { 
      "values": [[0, 0, 1, null]] 
    },
    "irradiation-2": { 
      "values": [[2, 2, 1, null]] 
    }
  }
}

7.2. Geometry Object having texture(s)

To store the texture(s) of a surface, a Geometry Object may have a member with the value "texture", its value is a collection of key-value pairs, where the key is the theme of the textures, and the value is one JSON object that must contain one member "values", whose value is a hierarchy of arrays with integers. For each ring of each surface, the first value refers to the position (0-based) in the "textures" member of the "appearance" member of the CityJSON object. The other indices refer to the UV positions of the corresponding vertices (as listed in the "boundaries" member of the geometry). Each array representing a ring therefore has one more value than that to store its vertices.

The depth of the array depends on the Geometry object, and is equal to the depth of the "boundary" array.

In the following, the Solid has 4 surfaces, and there are 2 themes: "winter-textures" and "summer-textures" could for instance represent the textures during winter and summer.. Notice that the last 2 surfaces of the first theme gets no material, thus null is used.

{
  "type": "Solid",
  "lod": 2,
  "boundaries": [
    [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]], [[1, 2, 6, 5]] ] 
  ],
  "texture": {
    "winter-textures": {
      "values": [
        [ [[0, 10, 23, 22, 21]], [[0, 1, 2, 6, 5]], [[null]], [[null]] ]                  
      ]
    },
    "summer-textures": {
      "values": [
        [ [[1, 10, 23, 22, 21]], [[1, 1, 2, 6, 5]], [[1, 66, 12, 64, 5]], [[2, 99, 21, 16, 25]] ]                  
      ]      
    }
  }     
}        

7.3. Material Object

A Material Object:

"materials": [
  {
    "name": "roofandground",
    "ambientIntensity":  0.2000,
    "diffuseColor":  [0.9000, 0.1000, 0.7500],
    "emissiveColor": [0.9000, 0.1000, 0.7500],
    "specularColor": [0.9000, 0.1000, 0.7500],
    "shininess": 0.2,
    "transparency": 0.5,
    "isSmooth": false
  },
  {
    "name": "wall",
    "ambientIntensity":  0.4000,
    "diffuseColor":  [0.1000, 0.1000, 0.9000],
    "emissiveColor": [0.1000, 0.1000, 0.9000],
    "specularColor": [0.9000, 0.1000, 0.7500],
    "shininess": 0.0,
    "transparency": 0.5,
    "isSmooth": true
  }            
]

7.4. Texture Object

A Texture Object:

"textures": [
  {
    "type": "PNG",
    "image": "http://www.hugo.com/filename.jpg"
  },
  {
    "type": "JPG",
    "image": "appearances/myroof.jpg",
    "wrapMode": "wrap",
    "textureType": "unknown",
    "borderColor": [0.0, 0.1, 0.2, 1.0]
  }      
]

7.5. Vertices-texture Object

A Appearance Object may have one member named "vertices-texture", whose value is an array of the (u,v) coordinates of the vertices used for texturing surfaces. Their position in this array (0-based) is used by the "texture" member of the Geometry Objects.

"vertices-texture": [
  [0.0, 0.5],
  [1.0, 0.0],
  [1.0, 1.0],
  [0.0, 1.0]
]

8. Extensions

CityJSON uses JSON Schemas to document and validate the data model, schemas should be seen as basically validating the syntax of a JSON document.

A CityJSON Extension is a JSON file that allows us to document how the core data model of CityJSON may be extended, and to validate CityJSON files. This is conceptually akin to the Application Domain Extensions (ADEs) in CityGML; see Section 10.13 of the official CityGML documentation.

The following 3 cases for extension are possible:

  1. Adding new complex attributes to existing City Objects

  2. Adding new properties at the root of a document

  3. Creating a new City Object, or "extending" one, and defining complex geometries

While Extensions are less flexible than CityGML ADEs (inheritance and namespaces are for instance not supported, and less customisation is possible), it should be noted that the flexibility of ADEs comes at a price: the software processing an extended CityGML file will not necessarily know what structure to expect. There is ongoing work to use the ADE schemas to automatically do this, but this currently is not supported by most software. Viewers might not be affected by ADEs because the geometries are usually not changed by an ADE. However, software parsing the XML to extract attributes and features might not work directly (and thus specific code would need to be written).

CityJSON Extensions are designed such that they can be read and processed by standard CityJSON software, often no changes in the parsing code is required. This is achieved by enforcing a set of simple rules, as defined below, when adding new City Objects. If these are followed, then a CityJSON file containing Extensions will be seen as a "standard" CityJSON file.

8.1. Using an Extension in a CityJSON file

An Extension should be given a name (eg "Noise") and the URL of the Extension file should be given, along with the version that is used for this file. It is expected that the Extension is publicly available at the URL, and can be downloaded.

Several Extensions can be used in a single file, each one is indexed by its name in the "extensions" JSON object. In the example below we have 2 Extensions: one named "Noise" and one named "Solar_Potential".

{
  "type": "CityJSON",
  "version": "1.0",
  "extensions": {
    "Noise": {
      "url" : "https://someurl.org/noise.json",
      "version": "1.0"
    },
    "Solar_Potential": {
      "url" : "https://someurl.org/solar.json",
      "version": "0.8"
    }
  },
  "CityObjects": {},
  "vertices": []
}

8.2. The Extension file

A CityJSON Extension is a JSON object, and it must have the following 7 members:

  1. one member with the name "type", whose value must be "CityJSON_Extension";

  2. one member with the name "name", whose value must be a string identifying the extension;

  3. one member with the name "uri", whose value must be a string with the URI of the location of the schema where the JSON object is located;

  4. one member with the name "version", whose value must be a string identifying the version of the Extension;

  5. one member with the name "extraRootProperties", whose value must be a JSON object; its content is part of a JSON schema (explained below), or an empty object;

  6. one member with the name "extraAttributes", whose value must be a JSON object; its content is part of a JSON schema (explained below), or an empty object;

  7. one member with the name "extraCityObjects", whose value must be a JSON object; its content is part of a JSON schema (explained below), or an empty object;

{
  "type": "CityJSON_Extension",
  "name": "Noise",
  "uri": "https://someurl.org/noise.json",
  "version": "0.1",
  "description": "Extension to model the noise"
  "extraRootProperties": {},     
  "extraAttributes": {},
  "extraCityObjects": {}
}

A CityJSON Extension object must be in a standalone file and it must be located in a folder /extensions in the folder where the CityJSON schemas are located. For a new extension noise.json the following structure would result:

|-- appearance.schema.json
|-- cityjson.schema.json
|-- cityobjects.schema.json
|-- geomprimitives.schema.json
|-- geomtemplates.schema.json
|-- metadata.schema.json
|-- /extensions
    |-- noise.json

This also means that if an element of the Extension reuses or references structures defined in the schemas of CityJSON, then the relative path ../ must be used. An example would be to reuse the Solid type would be:

"items": {
  "oneOf": [
    {"$ref": "../geomprimitives.json#/Solid"}
  ]
}

8.3. Case 1: Adding new complex attributes to existing City Objects

One of the philosophy of JSON is "schema-less", which means that one is allowed to define new properties for the JSON objects without documenting them in a JSON schema (watch out: this does not mean that JSON cannot have schemas!). While this is in contrast to CityGML (and GML as a whole) where the schemas are central, the schemas of CityJSON (schema) are partly following that philosophy. That is, for a given City Object, the "allowed" properties/attributes are listed in the schema, but it is not an error to add new ones. The "official validator" of CityJSON (cjio with the option --validate) does more than simply validate a dataset against the schemas, and will return a warning if an attribute is not in the schema, but it is not considered as invalid in CityJSON.

In brief, if one wants to simply add a new attribute to a given "Building", say to document its colour ("colour": "red"), the easiest way is just to add a property to the City Object (notice that "storeysAboveGround" is an allowed attributes to buildings):

{
  "type": "Building", 
  "attributes": { 
    "storeysAboveGround": 2,
    "colour": "red"
  },
  "geometry": [...]
}

It is also possible to add, and document in a schema, complex attributes, for example if we wanted to have the colour of the buildings as a RGBA value (red-green-blue-alpha):

{
  "type": "Building", 
  "attributes": { 
    "storeysAboveGround": 2,
    "+colour": {
      "rgba": [255, 255, 255, 1],
    },
  },
  "geometry": [...]
}

Another example would be to store the area of the parcel of a building, and to document also the unit of measurement:

{
  "type": "Building", 
  "attributes": { 
    "storeysAboveGround": 2,
    "+area-parcel": {
      "value": 437,
      "uom": "m2"
    } 
  },
  "geometry": [...]
}

For these 2 cases, the CityJSON Extension object would look like the snippet below. Notice that "extraAttributes" may have several properties (the types of the City Objects are the possibilities) and then each of these have as properties the new attributes (there can be several).

An extra attribute must start with a "+"; notice that it is good practice to prepend the attribute with the name of the Extension, to avoid that 2 attributes from 2 different extensions have the same name.

The value of the property is a JSON schema, this schema can reference and reuse JSON objects already defined in the CityJSON schemas.

"extraAttributes": {
  "Building": {
    "+colour": {
      "type": "object",
      "properties": {
        "rgba": {
          "type": "array",
          "items": {"type": "number"},
          "minItems": 4,    
          "maxItems": 4
        }
      },
      "required": ["rgba"],
      "additionalProperties": false
    },
    "+area-parcel": {
      "type": "object",
      "properties": {
        "value": { "type": "number" },
        "uom": { "type": "string", "enum": ["m2", "feet2"] }
      },
      "required": ["value", "uom"],
      "additionalProperties": false
    }      
  } 
}

8.4. Case 2: Adding new properties at the root of a document

It is allowed to add a new property at the root of a CityJSON file, but if one wants to document it in a schema, then this property must start with a "+". Imagine we wanted to store some census data for a given neighbourhood for which we have a CityJSON file, then we could define the extra root property "+census" as follows:

"extraRootProperties": {
  "+census": {
    "type": "object",
    "properties": {
      "percent_men": { 
        "type": "number",
        "minimum": 0.0,
        "maximum": 100.0
      },
      "percent_women": { 
        "type": "number",
        "minimum": 0.0,
        "maximum": 100.0
      }
    }
  }
}

And a CityJSON file would look like this:

{
  "type": "CityJSON",
  "version": "0.9",
  "CityObjects": {...},
  "vertices": [...],
  "+census": {
    "percent_men": 49.5,
    "percent_women": 51.5
  }
}

8.5. Case 3: Creating/extending new City Objects

The creation of a new City Object is done by defining it in the CityJSON Extension object in the "extraCityObjects" property:

"extraCityObjects": {
  "+NoiseBuilding": {
    "allOf": [
      { "$ref": "../cityobjects.json#/_AbstractBuilding" },
      {
        "properties": {
          "type": { "enum": ["+NoiseBuilding"] },
          "toplevel": {"type": "boolean"},
          "attributes": {
            "properties": {
              "buildingLDenMin": {"type": "number"}
            }
          }
        },
        "required": ["type"]
      }
    ]
  }
}

Since all City Objects are documented in the schemas of CityJSON (in cityobjects.json), it is basically a matter of copying the parts needed in a new file and modifying its content.

A new name for the City Object must be given and it must begin with a "+".

Because City Objects can be of different levels (1st-level ones can exist by themselves; 2nd-level ones need to have a parent), we need to explicitly state this by using the property "toplevel", which is a Boolean value.

It should be observed that since JSON schemas do not allow inheritance, the only way to extend a City Object is to define an entirely new one (with a new name, eg "+NoiseBuilding"). This is done by copying the schema of the parent City Object and extending it.

8.6. Rules to follow to define new City Objects

The challenge when creating Extensions to the core model is that we do not want to break the software packages (viewers, spatial analysis, etc) that already read and process CityJSON files. While one could define a new City Object and document it, if this new object does not follow the rules below then it will mean that new specific software needs to be built for it---this would go against the fundamental ideas behind CityJSON.

  1. The name of a new City Object must begin with a "+", eg "+NoiseBuilding".

  2. A new City Object must conform to the rules of CityJSON, ie it must contain a property "type" and one "geometry". If the object contains appearances, the same mechanism should be used so that the new City Objects can be processed without modification.

  3. A new City Object must contain the property "toplevel", whose value is a Boolean (true = 1st-level; false = 2nd-level).

  4. All the geometries must be in the property "geometry", and cannot be located somewhere else deep in a hierarchy of a new property. This ensures that all the code written to process, manipulate, and view CityJSON files will be working without modifications.

  5. If a new City Object contains other objects and requires different geometries, then a new City Object needs to be defined using the parent-children structure of CityJSON, as used by "Building" and "BuildingPart".

  6. The reuse of types defined in CityJSON, eg "Solid" or semantic surfaces, is allowed.

  7. To define a new semantic surface, a + must be prepended to its name, eg "+ThermalSurface".

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119