{"id":40895,"date":"2026-08-31T08:52:58","date_gmt":"2026-08-31T06:52:58","guid":{"rendered":"https:\/\/smartdatamodels.org\/?p=40895"},"modified":"2026-08-28T14:05:15","modified_gmt":"2026-08-28T12:05:15","slug":"cityjson-ciutygml-joins-smart-data-models-33-candidate-models-for-3d-city-objects","status":"publish","type":"post","link":"https:\/\/smartdatamodels.org\/index.php\/cityjson-ciutygml-joins-smart-data-models-33-candidate-models-for-3d-city-objects\/","title":{"rendered":"CityJSON\/ciutyGML Joins Smart Data Models: 33 Candidate Models for 3D City Objects"},"content":{"rendered":"

Smart Data Models’ Candidates repository<\/a> now includes a new candidate standard, cityjson-v2<\/code><\/strong>, translated from CityJSON v2.0.2<\/strong> \u2014 a JSON encoding of a subset of the OGC CityGML data model for 3D city models. All 33 core City Object types<\/strong> defined in cityjson\/specs<\/a>‘ schemas\/cityobjects.schema.json<\/code> now have an NGSI-LD \/ NGSI-v2 representation.<\/p>\n

What’s in it<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
Family<\/th>\nModels<\/th>\nExamples<\/th>\n<\/tr>\n<\/thead>\n
Building<\/td>\n8<\/td>\nBuilding<\/code>, BuildingPart<\/code>, BuildingUnit<\/code>, BuildingStorey<\/code>, BuildingRoom<\/code><\/td>\n<\/tr>\n
Bridge<\/td>\n6<\/td>\nBridge<\/code>, BridgePart<\/code>, BridgeInstallation<\/code>, BridgeConstructiveElement<\/code><\/td>\n<\/tr>\n
Tunnel<\/td>\n6<\/td>\nTunnel<\/code>, TunnelPart<\/code>, TunnelHollowSpace<\/code>, TunnelInstallation<\/code><\/td>\n<\/tr>\n
Transportation<\/td>\n4<\/td>\nRoad<\/code>, Railway<\/code>, TransportSquare<\/code>, Waterway<\/code><\/td>\n<\/tr>\n
Generic \/ furniture<\/td>\n3<\/td>\nGenericCityObject<\/code>, OtherConstruction<\/code>, CityFurniture<\/code><\/td>\n<\/tr>\n
Vegetation<\/td>\n2<\/td>\nPlantCover<\/code>, SolitaryVegetationObject<\/code><\/td>\n<\/tr>\n
Water, terrain, land use, grouping<\/td>\n4<\/td>\nWaterBody<\/code>, TINRelief<\/code>, LandUse<\/code>, CityObjectGroup<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Every model ships the full set of Candidates artifacts: a JSON Schema, an NGSI-LD @context<\/code>, and all four example serializations (NGSI-v2 and NGSI-LD, key-values and normalized) \u2014 each validated against its own schema.<\/p>\n

Built from real JSON Schema, mechanically \u2014 attributes included<\/h2>\n

Unlike some other Candidates translations that had to work from prose documentation pages, CityJSON ships genuine machine-readable JSON Schema files (schemas\/cityjson.schema.json<\/code>, cityobjects.schema.json<\/code>, geomprimitives.schema.json<\/code>, …). This translation parsed those directly, which surfaced a structural fact worth calling out: CityJSON’s own schema deliberately leaves attributes<\/code> open<\/strong> on every City Object type ({\"type\": \"object\"}<\/code>, no fixed sub-schema) \u2014 it defers attribute content to convention rather than declaring it.<\/p>\n

That convention is CityGML’s own data model, so this candidate goes one step further and cross-references the actual OGC CityGML 3.0 XML Schema<\/a> to promote real, typed, documented properties in place of the open bag: coded classification fields (class<\/code>, function<\/code>, usage<\/code>, roofType<\/code>), storey counts and heights, a qualified height<\/code> structure (CityGML 3.0’s structured replacement for the classic flat measuredHeight<\/code>), vegetation attributes (species<\/code>, trunkDiameter<\/code>, crownDiameter<\/code>, …), and three real closed enumerations resolved directly from the XSD (conditionOfConstruction<\/code>, height[].status<\/code>, trafficDirection<\/code>). Every model keeps a residual genericAttributes<\/code> property too \u2014 but that maps to CityGML’s own formal generic-attribute extension mechanism, not an invented catch-all.<\/p>\n

Three modeling decisions were made deliberately, not incidentally:<\/p>\n