@cityjson/cj-mcp 0.1.0

package/specs/chapters/the-different-city-objects.md

@@ -0,0 +1,571 @@
+## 2\. The different City Objects[](#the-different-city-objects)
+
+![City Objects 1st and 2nd levels](figs/co.svg)
+
+> **Note:** There are 2 kinds of City Objects:
+
+1.  **1st-level**: City Objects that can "exist by themselves" and cannot have a parent.
+    
+2.  **2nd-level**: City Objects that need to have a parent to exist.
+    
+
+This is because the schema of CityGML has been flattened. For example, `"BuildingInstallation"` instances cannot be present in a dataset without being `"children"` of a `"Building"`, but a `"Building"` can be present by itself.
+
+A City Object (1st or 2nd-level):
+
+*   **must** have one member with the name `"type"`. The value is one of the possibilities in the figure above (of type string). If an Extension is used, then the type can be any string starting with a `"+"`, as explained in [§ 8 Extensions](#extensions).
+    
+*   **may** have one member with the name `"geometry"`. The value is an array containing 0 or more Geometry Objects. More than one Geometry Object is used to represent several different levels-of-detail (LoDs) for the same object. However, the different Geometry Objects of a given City Object do not have to be of different LoDs.
+    
+*   **may** have one member with the name `"attributes"`. The value is an object where the attributes of the City Object are listed.
+    
+*   **may** have one member with the name `"geographicalExtent"`. The value is an array with 6 float values, which represent the axis-aligned bounding box of the City Object: `[minx, miny, minz, maxx, maxy, maxz]`.
+    
+*   **may** have one member with the name `"children"`. The value is an array of the IDs (of type string) of the City Object’s children. The array references only the City Object’s direct children (2nd-level) but not the grandchildren. For instance, the `"children"` array for the object "id-1" below links to a `"BuildingPart"` ("id-2") but not to the `"BuildingInstallation"` ("id-3") which is a child of the `"BuildingPart"`. A City Object can have different types of City Objects as children, eg a `"Building"` can have both as children `"BuildingPart"` and `"BuildingInstallation"`. The order of the children in the array is not relevant.
+    
+
+Additionally, a 2nd-level City Object:
+
+*   **must** have one member with the name `"parents"`. The value is an array with the IDs (of type string) of the City Object’s parents. For the City Objects in the CityJSON core module, this array will always be of size 1 (only one parent). New City Objects defined in extensions can have more than one parent.
+    
+
+"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"\],
+    "children": \["id-3"\],
+    ...
+  },
+  "id-3": {
+    "type": "BuildingInstallation", 
+    "parents": \["id-2"\],
+    ...
+  },
+  "id-4": {
+    "type": "LandUse", 
+    ...
+  }
+}
+
+An example of a minimal valid City Object is:
+
+{
+  "type": "Building"
+}
+
+The above example is for a `"Building"` City Object, but any 1st-level City Object can be encoded the same way.
+
+An example of a minimal 2nd-level valid City Object is:
+
+{
+  "type": "BuildingPart", 
+  "parents": \["id-parent"\]
+}
+
+The above example is for a `"BuildingPart"`, but any 2nd-level City Object can be encoded this way.
+
+### 2.1. Attributes for all City Objects[](#attributes-for-all-city-objects)
+
+The attributes for a given City Object must be stored in the `"attributes"` member and, unlike CityGML, they are not prescribed. Note that any valid JSON value (including an array and/or object) is a valid attribute value.
+
+"CityObjects": {
+  "id-1": {
+    "type": "LandUse", 
+    "attributes": { 
+      "function": "Industry and Business",
+      "area-parcel": {
+        "value": 437,
+        "uom": "m2"
+      },
+    },
+    "geometry": \[{...}\]
+  },
+  "id-2": {
+    "type": "WaterBody", 
+    "attributes": { 
+      "name": "Lake Black",
+      "some-list": \["a", "b", "c"\]
+    },
+    "geometry": \[{...}\]
+  }
+}
+
+### 2.2. Bridge[](#bridge)
+
+See the CityGML v3.0.0 [Bridge module](https://docs.ogc.org/is/20-010/20-010.html#toc44) for more details.
+
+Six City Objects are related to bridges:
+
+*   `"Bridge"`
+    
+*   `"BridgePart"`
+    
+*   `"BridgeInstallation"`
+    
+*   `"BridgeConstructiveElement"`
+    
+*   `"BridgeRoom"`
+    
+*   `"BridgeFurniture"`
+    
+
+The geometry of both `"Bridge"` and `"BridgePart"` can only be represented with these Geometry Objects: (1) `"Solid"`, (2) `"CompositeSolid"`, (3) `"MultiSurface"`, (4) `"CompositeSurface"`. The geometry of the four other objects can be represented with any Geometry Object.
+
+All the above City Objects, except `"Bridge"`, must have a `"parents"` member. The installations and furniture can have as parent a `"Bridge"`, a `"BridgePart"`, or a `"BridgeRoom"`.
+
+A City Object of type `"Bridge"` or `"BridgePart"` may have a member with the name `"address"`, whose value is an array of JSON objects listing one or more addresses of that bridge. The members of an address JSON object are not prescribed, to accommodate the different ways addresses are structured in different countries. If a location is necessary then a member with the name `"location"` can be added to the `"address"` member, and it should contain a `"MultiPoint"` geometry.
+
+"CityObjects": {
+  "LondonTower": {
+    "type": "Bridge", 
+    "address": \[
+      {
+        "city": "London",
+        "country": "UK"
+      }
+    \],
+    "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.3. Building[](#building)
+
+See the CityGML v3.0.0 [Building module](https://docs.ogc.org/is/20-010/20-010.html#toc45) for more details.
+
+Eight City Objects are related to buildings:
+
+*   `"Building"`
+    
+*   `"BuildingPart"`
+    
+*   `"BuildingInstallation"`
+    
+*   `"BuildingConstructiveElement"`
+    
+*   `"BuildingFurniture"`
+    
+*   `"BuildingStorey"`
+    
+*   `"BuildingRoom"`
+    
+*   `"BuildingUnit"`
+    
+
+The geometry of `"Building"`, `"BuildingPart"`, `"BuildingStorey"`, `"BuildingRoom"`, and `"BuildingUnit"` can only be represented with these Geometry Objects: (1) `"Solid"`, (2) `"CompositeSolid"`, (3) `"MultiSurface"`, (4) `"CompositeSurface"`. The geometry of `"BuildingInstallation"`, `"BuildingConstructiveElement"`, or `"BuildingFurniture"` objects can be represented with any Geometry Object.
+
+All the above City Objects, except `"Building"`, must have a `"parents"` member. The `"BuildingInstallation"`, `"BuildingConstructiveElement"`, `"BuildingFurniture"`, `"BuildingStorey"` can have as parent a `"Building"`, a `"BuildingPart"`, or a `"BuildingRoom"`.
+
+A City Object of type `"Building"`, `"BuildingPart"` or `"BuildingUnit"` may have a member with the name `"address"`, whose value is an array of JSON objects listing one or more addresses of that building (an apartment building for instance). The members of an address JSON object are not prescribed, to accommodate the different ways addresses are structured in different countries. If a location is necessary (eg to locate the position of the front door) then a member with the name `"location"` can be added to the `"address"` member, and it should contain a `"MultiPoint"` geometry.
+
+"CityObjects": {
+  "id-1": {
+    "type": "Building", 
+    "attributes": { 
+      "roofType": "gabled roof"
+    },
+    "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"\],
+    ...
+  }
+  ...
+}
+
+"myroom": {
+  "type": "BuildingRoom", 
+  "attributes": {
+    "usage": "living room"
+  },
+  "parents": \["id-1"\],
+  "geometry": \[{
+    "type": "Solid",
+    "lod": "2",
+    "boundaries": \[
+      \[ \[\[0, 3, 2, 1\]\], \[\[4, 5, 6, 7\]\], \[\[0, 1, 5, 4\]\], ... \]
+    \]
+  }\]    
+}               
+
+{
+  "type": "Building", 
+  "address": \[
+    {
+      "country": "Canada",
+      "locality": "Chibougamau",
+      "thoroughfareNumber": "1",
+      "thoroughfareName": "rue de la Patate",
+      "postcode": "H0H 0H0",
+      "location": {
+        "type": "MultiPoint",
+        "lod": "1",
+        "boundaries": \[231\]
+      }
+    }
+  \]
+}
+
+### 2.4. CityFurniture[](#cityfurniture)
+
+See the CityGML v3.0.0 [CityFurniture module](https://docs.ogc.org/is/20-010/20-010.html#toc32) for more details.
+
+The geometry of a City Object of type `"CityFurniture"` can be represented with any Geometry Object.
+
+"mystopsign": {
+  "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.5. CityObjectGroup[](#cityobjectgroup)
+
+See the CityGML v3.0.0 [CityObjectGroup module](https://docs.ogc.org/is/20-010/20-010.html#toc33) for more details.
+
+The CityGML concept of _groups_, which is used to aggregate City Objects based on certain criteria (think of a neighbourhood in a city for instance), is also adopted in CityJSON. The group is a City Object, and it can contain, if needed, a geometry (the polygon representing the neighbourhood for instance).
+
+Since a `"CityObjectGroup"` is also a City Object, it can be part of another group.
+
+A City Object of type `"CityObjectGroup"`:
+
+*   **must** have one member with the name `"children"`. The value is an array of the IDs (of type string) of the City Objects that the group contains. As for other City Objects, the City Objects must have the ID of the group in their `"parents"` member.
+    
+*   **may** have one member with the name `"children_roles"`. The value is an array of strings describing the role of each City Object in the group. This member must be of the same length as that of `"children"`.
+    
+*   **may** have one member with the name `"attributes"`. The value is an object where the attributes of the City Object are listed.
+    
+*   **may** have one member with the name `"geometry"`. The value is an array containing 0 or more Geometry Objects. Notice that since the `"CityObjectGroup"` is a container of different City Objects, the concept of Level of Detail does not apply to it. Nevertheless, the `"lod"` member is still used for enforcing uniformity with all the other geometries.
+    
+
+"CityObjects": {
+  "my-neighbourhood": {
+    "type": "CityObjectGroup",
+    "children": \["building1", "building2", "building3"\]
+  }
+}
+
+"CityObjects": {
+  "my-neighbourhood": {
+    "type": "CityObjectGroup",
+    "attributes": {
+      "location": "Chibougamau Sud"
+    },
+    "children": \["building1", "building3"\],
+    "children\_roles": \["residential building", "voting location"\],
+    "geometry": \[{
+      "type": "MultiSurface",
+      "lod": "2",
+      "boundaries": \[ \[\[2, 41, 5, 77\]\] \]
+    }\]
+  }
+}
+
+### 2.6. GenericCityObject[](#genericcityobject)
+
+While the CityGML v3.0.0 [Generics module](https://docs.ogc.org/is/20-010/20-010.html#toc35) has different classes for each [space type](https://docs.ogc.org/is/20-010/20-010.html#toc24), CityJSON has only one class to cover all 3 space types.
+
+This object should be used for objects that are not covered explicitly by any of the CityGML classes.
+
+The geometry of a City Object of type `"GenericCityObject"` can only be represented with these Geometry Objects: (1) `"MultiPoint"`, (2) `"MultiLineString"`, (3) `"MultiSurface"`, (4) `"CompositeSurface"`, (5) `"Solid"`, or (6) `"CompositeSolid"`.
+
+"whatisthat": {
+  "type": "GenericCityObject", 
+  "attributes": { 
+    "class": "a big bucket of water",
+    "usage": "it's not clear"
+  },
+  "geometry": \[{
+    "type": "CompositeSurface",
+    "lod": "1",
+    "boundaries": \[
+      \[\[0, 3, 2, 1\]\], \[\[4, 5, 6, 7\]\], \[\[0, 1, 5, 4\]\]
+    \]
+  }\]
+}
+
+### 2.7. LandUse[](#landuse)
+
+See the CityGML v3.0.0 [LandUse module](https://docs.ogc.org/is/20-010/20-010.html#toc36) for more details.
+
+The geometry of a City Object of type `"LandUse"` can only be represented with these Geometry Objects: (1) `"MultiSurface"` or (2) `"CompositeSurface"`.
+
+"oneparcel": {
+  "type": "LandUse", 
+  "geometry": \[{
+    "type": "MultiSurface",
+    "lod": "1",
+    "boundaries": \[
+      \[\[0, 3, 2, 1\]\], \[\[4, 5, 6, 7\]\], \[\[0, 1, 5, 4\]\]
+    \]
+  }\]    
+}
+
+### 2.8. OtherConstruction[](#otherconstruction)
+
+See the CityGML v3.0.0 [Construction module](https://docs.ogc.org/is/20-010/20-010.html#toc43) for more details (OtherConstruction is one class).
+
+This is used for constructions that are not buildings, bridges, or tunnels. Examples are:
+
+*   electricity pylon
+    
+*   fence
+    
+*   permanent water tank
+    
+*   pontoon
+    
+*   railway platform
+    
+*   shed
+    
+*   windmill
+    
+
+The geometry of a City Object of type `"OtherConstruction"` can be represented with any Geometry Object.
+
+"mypylon": {
+  "type": "OtherConstruction", 
+  "attributes": { 
+    "class": "windmill",
+    "conditionOfConstruction": "underConstruction"
+  },
+  "geometry": \[{
+    "type": "MultiSurface",
+    "lod": "2",
+    "boundaries": \[
+       \[\[0, 3, 2, 1\]\], \[\[4, 5, 6, 7\]\], \[\[0, 1, 5, 4\]\], ...
+    \]
+  }\] 
+}
+
+### 2.9. PlantCover[](#plantcover)
+
+See the CityGML v3.0.0 [Vegetation module](https://docs.ogc.org/is/20-010/20-010.html#toc40) for more details (PlantCover is one class).
+
+The geometry of a City Object of type `"PlantCover"` can only be represented with these Geometry Objects: (1) `"Solid"`, (2) `"CompositeSolid"`, (3) `"MultiSolid"`, (4) `"MultiSurface"`, (5) `"CompositeSurface"`.
+
+"myplants": {
+  "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\]\], \[\[111, 123, 922, 66\]\] \]
+      \]  
+    \]
+  }\]    
+}
+
+### 2.10. SolitaryVegetationObject[](#solitaryvegetationobject)
+
+See the CityGML v3.0.0 [Vegetation module](https://docs.ogc.org/is/20-010/20-010.html#toc40) for more details (SolitaryVegetationObject is one class).
+
+The geometry of a City Object of type `"SolitaryVegetationObject"` can be represented with any Geometry Object.
+
+"onebigtree": {
+  "type": "SolitaryVegetationObject", 
+  "attributes": { 
+    "trunkDiameter": 5.3,
+    "crownDiameter": 11.0
+  },
+  "geometry": \[{
+    "type": "MultiPoint",
+    "lod": "1",
+    "boundaries": \[1\]
+  }\]
+}
+
+### 2.11. TINRelief[](#tinrelief)
+
+See the CityGML v3.0.0 [Relief module](https://docs.ogc.org/is/20-010/20-010.html#toc38) for more details (TINRelief is one class).
+
+The geometry of a City Object of type `"TINRelief"` can only be represented with the Geometry Object `"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).
+
+Notice that in practice any `"CompositeSurface"` is allowed for encoding a terrain, and that arbitrary polygons could also be used (not just triangles).
+
+"myterrain01": {
+  "type": "TINRelief", 
+  "geographicalExtent": \[ 84710.1, 446846.0, \-5.3, 84757.1, 446944.0, 40.9 \],
+  "geometry": \[{
+    "type": "CompositeSurface",
+    "lod": "1",
+    "boundaries": \[
+       \[\[0, 3, 2\]\], \[\[4, 5, 6\]\], \[\[1, 2, 6\]\], \[\[2, 3, 7\]\], \[\[3, 0, 4\]\]
+    \]
+  }\]    
+}
+
+### 2.12. Transportation[](#transportation)
+
+See the CityGML v3.0.0 [Transportation module](https://docs.ogc.org/is/20-010/20-010.html#toc39) for more details.
+
+Four City Objects are related to transportation:
+
+*   `"Road"`
+    
+*   `"Railway"`
+    
+*   `"Waterway"`
+    
+*   `"TransportSquare"` (to model for instance parking lots and squares)
+    
+
+Observe that the "Section", "Intersection", and "Track" classes from CityGML are omitted because they can be easily specified using specific attributes.
+
+"ma\_rue": {
+  "type": "Road", 
+  "attributes": {
+    "class": "backwards",
+    "clearanceSpace": 2.23,
+    "clearanceSpaceUnit": "meter"
+  },
+  "children": \["sect1", "sect2"\],
+  "geometry": \[...\]
+}
+"sect1": {
+  "type": "Road", 
+  "attributes": {
+    "class": "section"
+  },
+  "parents": \["ma\_rue"\],
+  "geometry": \[...\],
+}
+
+Similarly, the CityGML classes "TrafficArea", "AuxiliaryTrafficArea", "Marking", and "Hole" are implemented as semantic surfaces (see [§ 3.3 Semantics of geometric primitives](#semantics-of-geometric-primitives)). That is, the surface representing a road should be split into sub-surfaces (therefore forming a `"MultiSurface"` or a `"CompositeSurface"`) in which each of the sub-surfaces has semantics.
+
+"ma\_rue": {
+  "type": "Road", 
+  "geometry": \[{
+    "type": "MultiSurface",
+    "lod": "2",
+    "boundaries": \[
+      \[\[0, 3, 2, 1, 4\]\], \[\[4, 5, 6, 9, 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.13. Tunnel[](#tunnel)
+
+See the CityGML v3.0.0 [Tunnel module](https://docs.ogc.org/is/20-010/20-010.html#toc46) for more details.
+
+Six City Objects are related to tunnels:
+
+*   `"Tunnel"`
+    
+*   `"TunnelPart"`
+    
+*   `"TunnelInstallation"`
+    
+*   `"TunnelConstructiveElement"`
+    
+*   `"TunnelHollowSpace"`
+    
+*   `"TunnelFurniture"`
+    
+
+The geometry of both `"Tunnel"` and `"TunnelPart"` can only be represented with these Geometry Objects: (1) `"Solid"`, (2) `"CompositeSolid"`, (3) `"MultiSurface"`, (4) `"CompositeSurface"`. The geometry of the other four objects can be represented with any Geometry Object.
+
+All the above City Objects, except `"Tunnel"`, must have a `"parents"` member. `"TunnelInstallation"`, `"TunnelConstructiveElement"`, `"TunnelHollowSpace"`, and `"TunnelFurniture"` can have as parents a `"Tunnel"` or a `"TunnelPart"`.
+
+"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.14. WaterBody[](#waterbody)
+
+See the CityGML v3.0.0 [WaterBody module](https://docs.ogc.org/is/20-010/20-010.html#toc42) for more details.
+
+The geometry of a City Object of type `"WaterBody"` can only be represented with these Geometry Objects: (1) `"MultiLineString"`, (2) `"MultiSurface"`, (3) `"CompositeSurface"`, (4) `"Solid"`, or (5) `"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\]\] \]
+    \]
+  }\]    
+}

package/specs/chapters/transform-object.md

@@ -0,0 +1,22 @@
+## 4\. Transform Object[](#transform-object)
+
+To reduce the size of a CityJSON object (and thus the size of files) and to ensure that only a fixed number of digits is stored for the coordinates of the geometries, the coordinates of the vertices of the geometries are represented with integer values. We therefore need to store the scale factor and the translation needed to obtain the original coordinates (stored with floats/doubles).
+
+In the example below, the `"scale"` member indicates that 3 important digits are kept (thus millimetre level if meters are the units of the CRS). The values of the `"translate"` member usually matches with the minimum values of the axis-aligned bounding box (but does not need to).
+
+"transform": {
+    "scale": \[0.001, 0.001, 0.001\],
+    "translate": \[442464.879, 5482614.692, 310.19\]
+}
+
+A CityJSON object must therefore 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)](https://github.com/topojson/topojson-specification/blob/master/README.md#212-transforms) is reused, and here we simply add a third coordinate because our vertices are embedded in 3D space.
+
+It should be noticed that only the `"vertices"` at the root of the CityJSON object are affected by the transformation, the vertices for the Geometric templates and textures are not.
+
+We can obtain the real coordinates of a given vertex _v_, from the _vi_ values listed in the `"vertices"` member as follows:
+
+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\]