Cityjson Specs Versions Save

Specifications for CityJSON, a JSON-based encoding for 3D city models

2.0.1

1 month ago

[2.0.1] - 2024-04-11

Changed

  • "metadata" allows additional non-listed properties (than the 6 by ISO). For more structured metadata it is advised to make use of the metadata-extended Extension
  • the schemas now enforce "type" for Semantic Surface
  • schemas now verify that "boundaries" having an empty list is an error
  • the "lod" for geometries are now restrained to those of CityGML and the extended-LoD by TUDelft (as the specifications already mentioned, but the schemas allowed anything X.Y)
  • fix 3 typos in the specifications

2.0.0

8 months ago

[2.0.0] - 2023-09-27

  • this version is basically v1.1 with small fixes (see below) and an improved/clearer text
  • the major version change to 2.0 was required by the OGC to be officially approved

Changed

  • GenericCityObject is back as a City Object in the data model, because it makes life easy for everyone and it is there in the v3.0 data model (albeit those are specific to the SPACES, which are not implemented in CityJSON)
  • it is now possible to define extra Semantic Surfaces in Extensions (with "extraSemanticSurfaces"), which is a mandatory property of the schema
  • "metadata/pointOfContact" is now a JSON object, like other addresses for Buildings/Bridges
  • the text of the specs has been improved and harmonised (there were some inconsistencies, for instance with addresses for City Objects and metadata)
  • the values of u and v for textures are allowed to be outside [0.0, 1.0] to allow repeated patterns.

1.1.3

1 year ago

Patch release where the schemas are essentially the same, and where the text of the specs is better/sharper.

Changed

  • CityJSONFeatures now do not have to dereference the GeometryTemplates, those can be in the "1st line"/metadata. Dereferencing is still allowed. cjio passes the GeometryTemplates in the 1st-line now.
  • CityJSONFeature: now clear that all children (recursively) of a feature should be bundled with its parent.
  • improved the text of the specifications at several places, and fixed sentences that were not precise enough.
  • change the "uri" to "url" for the Extensions, and now the schemas can have either of these. Going forward "url" is the preferred way.
  • restructured the text for the Extensions, now a 4th use-case is added: "Defining a new Semantic Object". It was always there but not listed as a case. Now fixed.

Added

  • "BuildingConstructiveElement" was missing from the schemas as a CO, now added.
  • added 2 suggested conventions in the specs: file extensions .city.json and .city.jsonl

1.1.2

1 year ago

Minor changes to the schemas for errors, improved the text of the specs so that it's easier for everyone to read and understand.

Changed

  • fixed the typo in the schema: "TunnelFurniture"
  • added the missing CityGML v3 types in the schemas: "BridgeFurniture" and "Waterway" and "BuildingConstructiveElement"
  • added a link in the specs text to the official CityGML v3 specs for definitions of each of the City Objects
  • improved and added a few sentences in the specs to make them clearer

1.1.1

1 year ago

Minor changes to the schemas for omissions/errors, harmonised the specs text slightly.

Removed

Changed

  • added Semantic types for interior surfaces: "FloorSurface", "InteriorWallSurface", and "CeilingSurface".
  • the restrictions for the geometry types for different City Objects are harmonised
  • MultiPoint and MultiLineString can have semantics (it was in the text but not in the schema)
  • added "address" property for BuildingUnit in the schema (was already described in the text)
  • the property "children_roles" of "CityObjectGroup" can have NULL values if not used
  • the specs text now is correct for the appearance: "vertices-texture" and not "vertex-texture"

1.1.0

1 year ago

Added

  • add support for CityGML v3.0.0:
    • add interior of Buildings/Tunnels/Bridges classes, eg BuildingStorey, BuildingUnit, BuildingRoom, BridgeRoom
    • add OtherConstruction
    • updated Transportation classes to be compliant
  • CityJSONFeature is defined, which can be used for streaming and handling large files

Removed

  • GenericCityObject has been removed, Extensions should be used instead

Changed

  • change the property "lod" of geometries from number to string
  • core metadata is smaller, extended/advanced metadata are now in the MetadataExtended Extension: https://github.com/cityjson/metadata-extended
  • CityJSON files are always compressed, that is their vertices are integers and the "transform" property is mandatory
  • City Objects do not have to have a "geometry" property anymore
  • CityObjectGroup has the role added as a property, to define what the role of each object in the group is
  • CRS now use the OGC Name Type Specification (https://docs.opengeospatial.org/pol/09-048r5.html)

0.9

1 year ago

Changed

  • the "parent" property of City Objects is now named "parents": [], and is an array. This is to allow new City Objects in Extensions to have more than one parent; for the core objects this doesn't change anything (except that the property must be renamed and put an array; cjio upgrade_version() takes care of this)
  • the schemas have been revamped. The content is the same, but there are now abstract objects and city objects reuse these. It's thus way easier to modify and update and understand the schemas
  • the Extensions are not schemas files anymore, but JSON files with a specific syntax. The idea is the same, but now creating Extensions is simpler.
  • Extensions now allow new attributes for already existing City Objects, ie it's possible to add an attribute "+myattribute" to a "Building" and document it in a schema. Before it was only possible if one created a new specific City Object.
  • Extensions now allow root properties to be added and documented.
  • Transportation module now has LoD0 with MultiLineString geometries.

1.0.0

1 year ago

Changed

  • Semantic versioning is from on now used, with MAJOR.MINOR.PATCH
  • The "extensions" property now documents the version of the Extension that is used for this file; since an Extension will most likely be updated it should be possible to link to a specific version (X.Y)
  • new logo!