@cityjson/cj-mcp 0.1.0

package/specs/chapters/handling-large-files.md

@@ -0,0 +1,93 @@
+## 7\. Handling large files[](#handling-large-files)
+
+Because CityJSON aims at being easy-to-use and developer-friendly, it is advised to keep the size of CityJSON files small. Files of several hundreds of megabytes are bad practice, and should be avoided since users will have great difficulties visualising and manipulating them.
+
+### 7.1. Decomposing an area into parts/tiles[](#decomposing-an-area-into-parts-tiles)
+
+One solution to handle a large dataset is to subdivide it into tiles or regions, and ensure that each part has a reasonable size. Each part becomes a CityJSON file.
+
+### 7.2. Text sequences and streaming with CityJSONFeature[](#text-sequences-and-streaming-with-cityjsonfeature)
+
+Another solution is to decompose a CityJSON object into its _features_ (the City Objects), create several JSON objects, and store them in a [JSON Text Sequences](https://datatracker.ietf.org/doc/html/rfc7464) (one example being [JSON Lines](https://jsonlines.org)). This is a format to store several JSON objects in a single file, and allows the processing of each object one at a time.
+
+A CityJSON Feature Object allows the storage of a single feature, for instance a `"Building"` together with its children (of type `"BuildingPart"` and/or `"BuildingInstallation"`). Unlike a CityJSON Object, all the vertices and appearances of the object are _local_.
+
+A CityJSON Feature Object:
+
+*   is a JSON object.
+    
+*   **must** have one member with the name `"type"`. The value must be `"CityJSONFeature"`.
+    
+*   **must** have one member with the name `"id"`. The value must be a string representing the identifier of the City Object Feature. This is used to clearly identify which of the CityObjects is the parent.
+    
+*   **must** have one member with the name `"CityObjects"`. The value is a collection of key-value pairs, where the key is the ID of the object, and the value is one City Object. The ID of a City Object should be unique (within one `"CityJSONFeature"`), and all the children of the `"CityJSONFeature"` must be included (and the children of the children (recursively), if there are any).
+    
+*   **must** have one member with the name `"vertices"`. The value is an array of coordinates of each vertex of the current City Object Feature (stored with integers). Their position in this array (0-based) is used as an index to be referenced by the Geometry Objects for the JSON object (warning: the vertices are local to the JSON object).
+    
+*   **may** have one member with the name `"appearance"`. The value may contain JSON objects representing the textures and/or materials of surfaces. See [§ 6 Appearance Object](#appearance-object) for details.
+    
+*   **must not** have other members.
+    
+
+{
+  "type": "CityJSONFeature",
+  "id": "myid", 
+  "CityObjects": {},
+  "vertices": \[\],
+  "appearance": {}
+}
+
+{
+  "type": "CityJSONFeature",
+  "id": "id-1", 
+  "CityObjects": {
+    "id-1": {
+      "type": "Building", 
+      "attributes": { 
+        "roofType": "gabled roof"
+      },
+      "children": \["mypart"\],
+      "geometry": \[...\]
+    },
+    "mypart": {
+      "type": "BuildingPart", 
+      "parents": \["id-1"\],
+      "children": \["mybalcony"\],
+      "geometry": \[...\]
+    },
+    "mybalcony": {
+      "type": "BuildingInstallation", 
+      "parents": \["mypart"\],
+      "geometry": \[...\]
+    }
+  },
+  "vertices": \[...\]
+}
+
+The following root members of a CityJSON Object are not allowed in a CityJSONFeature Object:
+
+*   `"transform"`
+    
+*   `"version"`
+    
+*   `"metadata"`
+    
+*   `"geometry-templates"`: these should either be resolved/dereferenced, or they should be placed in the metadata or collection
+    
+*   `"extensions"`: these should be placed in the metadata or collection
+    
+
+Note that a CityJSON Feature Object does not contain all the information that is required for parsing the feature. Most commonly, the transformation properties (the Transform Object) and CRS must be known by the client in order to correctly georeference the City Objects. These properties may be known by the client upfront, or they may be accessible in a CityJSON Object, which is sent as the first object in a [JSON Lines text](https://jsonlines.org/) stream, or in other ways not described here (for instance RESTful APIs often have a mechanism to retrieve metadata).
+
+In case the properties are stored in a CityJSON Object, this object needs to be a valid CityJSON Object. This implies that the CityJSON object must contain all the required properties, including `"CityObjects"` and `"vertices"`, even though they are empty, because this information is stored in the subsequent CityJSON Features.
+
+Below is an example of a CityJSONFeature stream (or a JSON Lines text file), with a CityJSON Object storing the metadata and transformation properties, as well as geometry templates:
+
+{"type":"CityJSON","version":"2.0","transform":{...},"CityObjects":{},"metadata":{...},"vertices":\[\], "geometry-templates":{...}}
+{"type":"CityJSONFeature","id":"a","CityObjects":{...},"vertices":\[...\]} 
+{"type":"CityJSONFeature","id":"b","CityObjects":{...},"vertices":\[...\]} 
+{"type":"CityJSONFeature","id":"c","CityObjects":{...},"vertices":\[...\]} 
+
+> **Note:** **Suggested convention:** `"CityJSON"` and `"CityJSONFeature"` objects may be stored in a file with the extension `'.city.jsonl'`
+
+> **Note:** Observe that CityJSON does not prescribe the format or standard that should be used to store several JSON objects in a given file, it only defines how `"CityJSON"` and `"CityJSONFeature"` objects should be defined.

package/specs/chapters/metadata.md

@@ -0,0 +1,118 @@
+## 5\. Metadata[](#metadata)
+
+The core of CityJSON supports the following six properties, which are compliant with the international standard [ISO19115](https://www.iso.org/standard/53798.html).
+
+"metadata": {
+  "geographicalExtent": \[ 84710.1, 446846.0, \-5.3, 84757.1, 446944.0, 40.9 \],
+  "identifier": "eaeceeaa-3f66-429a-b81d-bbc6140b8c1c",
+  "pointOfContact": {
+    "contactName": "3D geoinformation group, Delft University of Technology",
+    "contactType": "organization",
+    "role": "owner",
+    "phone": "+31-6666666666",
+    "emailAddress": "3dgeoinfo-bk@tudelft.nl",
+    "website": "https://3d.bk.tudelft.nl",
+    "address": {
+      "thoroughfareNumber": "134",
+      "thoroughfareName": "Julianalaan",
+      "locality": "Delft",
+      "postcode": "2628BL",
+      "country": "the Netherlands"
+    }
+  },
+  "referenceDate": "1977-02-28",
+  "referenceSystem": "https://www.opengis.net/def/crs/EPSG/0/2355",
+  "title": "Buildings in LoD2.3 of Chibougamau, Québec"
+}
+
+> **Note:** The storage of additional ISO19115-compliant metadata attributes and/or of statistics related to 3D city models can be done with the [MetadataExtended Extension](https://github.com/cityjson/metadata-extended). Examples of extra attributes/properties that can be stored: point of contact for the dataset, lineage, statistics about the present LoDs, the presence of textures/materials, etc.
+
+### 5.1. geographicalExtent (bbox)[](#geographicalextent-bbox)
+
+While the geographical extent can be computed from the dataset itself, it is often useful to store it. It may be stored as an array with 6 values: `[minx, miny, minz, maxx, maxy, maxz]`. Notice that these values are in the real-world coordinate system of the dataset (based on [§ 5.5 referenceSystem (CRS)](#referencesystem-crs)) and have not been compressed with the `"transform"` member ([§ 4 Transform Object](#transform-object)) as the `"vertices"` have been.
+
+"metadata": {
+  "geographicalExtent": \[ 84710.1, 446846.0, \-5.3, 84757.1, 446944.0, 40.9 \]
+}
+
+### 5.2. identifier[](#identifier)
+
+A unique identifier for the dataset. It is recommended to use a [universally unique identifier](https://en.wikipedia.org/wiki/Universally_unique_identifier), but it is not obligatory.
+
+"metadata": {
+  "identifier": "44574905-d2d2-4f40-8e96-d39e1ae45f70"
+}
+
+### 5.3. pointOfContact[](#pointofcontact)
+
+The point of contact for the dataset. This is a JSON object that
+
+*   **must** have one member with the name `"contactName"`. The value is the name of the contact.
+    
+*   **must** have one member with the name `"emailAddress"`. The value is a string with the email.
+    
+*   **may** have one member with the name `"role"`. The value describes the role that contact person/organisation has, it is one of the following: `"resourceProvider"`, `"custodian"`, `"owner"`, `"user"`, `"distributor"`, `"originator"`, `"pointOfContact"`, `"principalInvestigator"`, `"processor"`, `"publisher"`, `"author"`, `"sponsor"`, `"co-author"`, `"collaborator"`, `"editor"`, `"mediator"`, `"rightsHolder"`, `"contributor"`, `"funder"`, `"stakeholder"`.
+    
+*   **may** have one member with the name `"website"`. The value is the URL of point of contact.
+    
+*   **may** have one member with the name `"contactType"`. The value is a string which is either `"individual"` or `"organization"`. For an `"organization"`, the `"website"` can also be given.
+    
+*   **may** have one member with the name `"address"`. The value is a JSON object and any properties can be used, to accommodate the different ways addresses are structured in different countries.
+    
+*   **may** have one member with the name `"phone"`. The value is a string with the phone number.
+    
+*   **may** have one member with the name `"organization"`. The value is the name of the organisation, to be used if the `"contactName"` is the name of a person.
+    
+
+"pointOfContact": {
+  "contactName": "Justin Trudeau",
+  "emailAddress": "justin.trudeau@parl.gc.ca",
+  "phone": "+1-613-992-4211",
+  "address": {
+    "thoroughfareNumber": "24",
+    "thoroughfareName": "Sussez Drive",
+    "postcode": "H0H 0H0",
+    "locality": "Ottawa",
+    "country": "Canada"
+  },    
+  "contactType": "individual",
+  "role": "pointOfContact"
+}
+
+### 5.4. referenceDate[](#referencedate)
+
+The date when the dataset was compiled, without the time of the day, only a `"full-date"` as defined in [RFC 3339, Section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6) should be used.
+
+"metadata": {
+  "referenceDate": "1977-02-28"
+}
+
+> **Note:** JSON does not have a date type, and thus the representations defined by [RFC 3339, Section 5.6](https://tools.ietf.org/html/rfc3339#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.
+
+Other attributes in a CityJSON object can also have a date with a time, and such an attribute is specified as a `"full-time"`. For example `"1985-04-12T23:20:50.52Z"` (stored as a string).
+
+### 5.5. referenceSystem (CRS)[](#referencesystem-crs)
+
+The coordinate reference system (CRS) is given as a URL formatted according to the [OGC Name Type Specification](https://docs.opengeospatial.org/pol/09-048r5.html#_production_rule_for_specification_element_names):
+
+http://www.opengis.net/def/crs/{authority}/{version}/{code}
+
+where `{authority}` designates the authority responsible for the definition of this CRS (usually "EPSG" or "OGC"), and where `{version}` designates the specific version of the CRS ("0" (zero) is used if there is no version).
+
+For instance, the Dutch national CRS in 3D:
+
+"metadata": {
+  "referenceSystem": "https://www.opengis.net/def/crs/EPSG/0/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.
+
+> **Note:** Unlike in (City)GML where each object can have a different CRS (eg a wall of a building could theoretically have a different CRS from the other walls in the same the building), in CityJSON all the city objects need to be in the same CRS.
+
+### 5.6. title[](#title①)
+
+A string describing the dataset.
+
+"metadata": {
+  "title": "3D city model of Chibougamau, Canada"
+}

package/specs/chapters/profile-and-date.md

@@ -0,0 +1,22 @@
+## Living Standard, 20 December 2025
+
+**This version:**
+: [https://cityjson.org/specs/2.0.1/](https://cityjson.org/specs/2.0.1/)
+
+**Latest published version:**
+: [https://cityjson.org/specs/](https://cityjson.org/specs/)
+
+**Previous Versions:**
+: [https://cityjson.org/specs/overview/](https://cityjson.org/specs/overview/)
+
+**Feedback:**
+: [GitHub](https://github.com/cityjson/specs/issues/)
+
+**Editors:**
+: [Hugo Ledoux](https://3d.bk.tudelft.nl/hledoux) (TU Delft)
+
+: [Balázs Dukai](https://3dgi.nl) (3DGI)
+
+[![CC0](https://licensebuttons.net/p/zero/1.0/80x15.png)](http://creativecommons.org/publicdomain/zero/1.0/) To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 20 December 2025, the editors have made this specification available under the [Open Web Foundation Agreement Version 1.0](https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0), which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.
+
+* * *