ETSI GS CIM 050 V1.1.1 (2024-11)

Context Information Management (CIM); Aligning with geo-information

DGS/CIM-0050

General Information

• Status: Not Published
• Technical Committee: CIM - cross-cutting Context Information Management
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 15-Nov-2024
• Completion Date: 15-Nov-2024

Standards Content (Sample)

GROUP SPECIFICATION
Context Information Management (CIM);
Aligning with geo-information
Disclaimer
The present document has been produced and approved by the cross-cutting Context Information Management (CIM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS CIM 050 V1.1.1 (2024-11)

Reference
DGS/CIM-0050
Keywords
API, IoT, NGSI-LD
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI GS CIM 050 V1.1.1 (2024-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Recommendations derived from ETSI GR CIM 049 . 8
4.1 Lessons learned from the analysis of use cases documented in ETSI GR CIM 049 . 8
4.2 Topics from ETSI GR CIM 049 and associated standards or technologies. 8
4.2.1 The 10-minute city . 8
4.2.2 Underground Utilities Networks . 9
4.3 Disaster and emergency . 9
4.3.0 Foreword . 9
4.3.1 Challenge of defining regions of interest . 10
4.4 The need to work at different scales . 11
4.5 Local Digital Twins . 12
4.6 The challenge of data models . 12
4.7 Identifiers . 13
4.8 Towards more sophisticated modelling techniques . 13
4.9 Issues with software . 13
5 Geographic standards in scope . 13
6 Extending NGSI-LD. 14
6.1 Method . 14
6.2 Information about GeoProperty, Coordinates and CRS . 14
6.3 coordRefSys subproperty . 15
6.4 Level Of Detail . 16
6.4.1 LOD . 16
6.4.2 LOIN . 17
6.5 3DShape . 18
6.6 GeoQuery . 19
Annex A (informative): Descriptions of Standards . 22
Annex B (informative): Change history . 25
History . 26

ETSI
4 ETSI GS CIM 050 V1.1.1 (2024-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) cross-cutting Context
Information Management (CIM).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document specifies how to make geodata accessible as Linked Data. It proposes changes and enhancements
to ETSI GS CIM 006 [5] and ETSI GS CIM 009 [1].
Introduction
The present document is complementary to ETSI GR CIM 049 [i.21]. The use cases that ETSI GR CIM 049 [i.21] has
documented show that many cities and communities use both geographical systems and NGSI-based systems and will
continue in the future.
By further analysing the results and ideas of ETSI GR CIM 049 [i.21], which are derived from interviews with a large
number of smart cities representatives, the present document recommends changes to ETSI GS CIM 006 [5] and ETSI

GS CIM 009 [1].
ETSI
5 ETSI GS CIM 050 V1.1.1 (2024-11)
1 Scope
The present document specifies how to make geodata accessible as Linked Data. It specifies how to share spatial (and
spatio-temporal) data, and how to make them interoperable with, within, and between systems and territories. It also
specifies how to both establish and maintain the number of connections between NGSI-LD Entities (see ETSI
GS CIM 009 [1]) and their geographical 2D/3D representations.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS CIM 009 (V1.8.1): "Context Information Management (CIM); NGSI-LD API".
[2] IETF RFC 7946: "The GeoJSON Format". ®
[3] OGC GeoSPARQL: "A Geographic Query Language for RDF Data".
[4] ISO/IEC 12113:2022: "Information technology — Runtime 3D asset delivery format — Khronos
glTF™ 2.0".
[5] ETSI GS CIM 006: "Context Information Management (CIM); NGSI-LD Information Model". ®
[6] OGC : "OGC Name Type Specification - Definitions - part 1 - basic name". ®
[7] OGC RAINBOW: "Collections".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area. ®
[i.1] W3C : "Universal Resource Identifier (URI)".
[i.2] Eric Evans, Addison-Wesley Professional, 2003: "Domain-Driven Design (DDD): Tackling
Complexity in the Heart of Software".
[i.3] Open Agile Architecture™, Part 2: The O-AA Building Blocks: "Domain-Driven Design:
Strategic Patterns".
ETSI
6 ETSI GS CIM 050 V1.1.1 (2024-11)
® ®
[i.4] Open Geospatial Consortium Inc. OGC 06-103r4: "OpenGIS Implementation Standard for
Geographic information - Simple feature access - Part 1: Common architecture".
[i.5] FIWARE, IUDX, TM Forum, OASC and others: "Parking Smart Data Model". ®
[i.6] Digital Twin Consortium: "Digital Twin definition". ®
[i.7] OGC : "Geography Markup Language (GML)". ®
[i.8] OGC : "CityGML". ®
[i.9] OGC : "CityJSON". ®
[i.10] OGC : "IndoorGML". ®
[i.11] OGC : "API - Features - Part 1: Core". ®
[i.12] OGC : "API - Features - Part 2: Coordinate Reference Systems by Reference". ®
[i.13] OGC : "Coordinate Transformation Service. ®
[i.14] W3C : "Time Ontology in OWL".
[i.15] Building Smart: "IFC Industry Foundation Classes 4.0.2.1: Version 4.0 - Addendum 2 - Technical
Corrigendum 1".
NOTE: Published also as ISO 16739-1:2018.
[i.16] Interoperable Europe Programme: "GeoDCAT-AP".
[i.17] EC DG JRC Unofficial Draft 31 May 2024: "DCAT-AP-JRC - Version 2".
[i.18] ETSI GR CIM 048 (V1.1.1): "Context Information Management (CIM); Handling of data
catalogues and data services with NGSI-LD".
[i.19] ETSI DGR/CIM-0055: "Context Information Management (CIM); Handling of services execution
in NGSI-LD based systems".
[i.20] ArcGIS - ESRI.
[i.21] ETSI GR CIM 049: "Context Information Management (CIM); Usage of geo-information".
[i.22] Filip Biljecki, Hugo Ledoux, and Jantien Stoter: "An improved LOD specification for 3D building
models". Computers, Environment and Urban Systems, 59: 25–37, 2016.
[i.23] ISO 7817-1:2024: "Building information modelling — Level of information need, Part 1:
Concepts and principles".
[i.24] ISO 19650-1:2018: "Organization and digitization of information about buildings and civil
engineering works, including building information modelling (BIM) — Information management
using building information modelling, Part 1: Concepts and principles". ®
[i.25] W3C : "Building Topology Ontology", Draft Community Group Report 28 June 2021.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
ETSI
7 ETSI GS CIM 050 V1.1.1 (2024-11)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AI Artificial Intelligence
AP Application Profile
NOTE: Part of DCAT-AP.
API Application Programming Interface
AP-JRC Application Profile – Join Research Center
NOTE: Part of DCAT-AP-JRC.
AR Augmented Reality
BIM Building Information Modelling
CAD Computer Aided Design
CityGML City Geography Markup Language
CRS Coordinate Reference System
DCAT Data Catalog vocabulary
DDD Domain Driven Design
EU European Union
GIS Geographic Information System
glTF gl Transmission Format
GML Geography Markup Language
GNSS Global Navigation Satellite System
GPS Global Positioning System
GPU Graphic Processing Unit
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HVAC Heating Ventilation Air Conditioning
ID IDentifier
JSON JavaScript Object Notation
KML Keyhole Markup Language
LD Linked Data
LOD Level Of Details
LOIN Level Of Information Need
NGSI Next Generation Service Interfaces
NGSI-LD Next Generation Service Interface - Linked Data.
OGC Open Geospatial Consortium
OWL Web Ontology Language
QGIS Quantum Geographic Information System
RDF Resource Description Format
SPARQL SPARQL Protocol And RDF Query Language
SQL Standard Query Language
TTL Terse RDF Triple Language
NOTE: Pronounced "turtle".
URI Uniform Resource Identifier
URL Unified Resource Locator
VR Virtual Reality
WGS World Geodetic System
WKT Well-Known Text
XML eXtensible Markup Language
XSD eXtensible markup language Schema Definition
ETSI
8 ETSI GS CIM 050 V1.1.1 (2024-11)
4 Recommendations derived from ETSI GR CIM 049
4.1 Lessons learned from the analysis of use cases
documented in ETSI GR CIM 049
The use cases that ETSI GR CIM 049 [i.21] has documented show that many cities and communities use both
geographical systems and NGSI-based systems and will continue in the future. Several of those use cases require some
level of interoperability between geographical software components and NGSI ones.
The interoperability needs can be illustrated by two simple examples:
• A city would like to provide a service enabling a citizen or tourist to indicate a geographical location and
obtain a list of events (e.g. a concert, an exhibition, etc.) to which he or she could join. The list of events and
their description is managed by a Context Broker that implements a Cultural Events Smart Data Model.
• The team that manages the gardens using an application that implements a Garden Smart Data Model needs to
access garden information contained in the geographical system and keep that information consistent in both
systems. For example, the geographical system using some AI capabilities identifies that a tree has died. The
garden team needs to be informed to take care of the dead tree.
For practical reasons as well as economical ones, it would not make sense to (re)-develop cultural events management
use cases in the geographical system or (re)-develop geographical mapping features in the garden management system.
The OGC/NGSI interoperability initiatives that were analysed such as the OGC incubator or the Civitas Connect
initiative are developing NGSI-LD domain models that mirror the corresponding OGC models (i.e. a Battery model for
Civitas Connect and an airport facility model for the OGC incubator). This type of approach does not meet all the needs
of the use cases have been analysed. It is not only needed to specify how to translate from one domain model to another
(static view), but it is also needed to specify how to model the behaviour of a composite system (e.g. a city digital twin
[i.6]) made of heterogenous subsystems (dynamic view).
On the static side, OGC models can be represented as Domain-Specific Ontologies. The potential loss of semantic
information results from the fact that NGSI-LD API does not support sub-typing of Entity Types.
On the dynamic side, providing that both OGC and NGSI-LD support a subscription functionality, it is possible to
implement the type of interactions that Local Digital Twin need to model. However, additional features need to be
added to the NGSI-LD specifications and new modelling practices need to be adopted.
Some cities are using the transition to digital twins as a way of breaking out from the siloed way they operate. They are
creating cross-functional working groups dedicated to the development and operation of digital twins. This
organizational evolution is necessary to effectively manage the new types of interactions demanded by digital twins.
4.2 Topics from ETSI GR CIM 049 and associated standards or
technologies
4.2.1 The 10-minute city
The key issues highlighted in ETSI GR CIM 049 [i.21] focus on data quality and the pathfinding algorithms within the
applications. While NGSI-LD doesn't directly address the algorithms used in routing apps, it plays a crucial role in
ensuring the data behind those routes is timely and accurate. By leveraging the observedAt, createdAt, or modifiedAt
properties in an NGSI-LD response, people can deliver the real-time, reliable data that great routing depends on.
Implementors are reminded to refer to ETSI GS CIM 009 [1], clause 6.3.11.
Recommendation: add the following note in a future revision of ETSI GS CIM 009 [1], clause 4.8, to help the
implementors meet the objectives on the data quality timeliness of the system generated Temporal Attributes:
NOTE: Implementors are recommended to request the TemporalProperty values when the timeliness of the
data is an important data quality criteria for their use cases. For example, in case of HTTP binding, see
ETSI GS CIM 009 [1], clause 6.3.11.
ETSI
9 ETSI GS CIM 050 V1.1.1 (2024-11)
4.2.2 Underground Utilities Networks
Simple graph network representations with 2D or 3D polylines, using OGC Features for the components, are usually
enough to represent and share context information for utilities networks.
When dealing with underground artefacts, the elevation (depth) of the artefact can be specified using a GeoJSON
geometric object that includes altitude as specified in IETF RFC 7946 [2] and quoted in the present document in italics
as follows:
"A position is an array of numbers. There MUST be two or more elements. The first two elements are longitude and
latitude, or easting and northing, precisely in that order and using decimal numbers. Altitude or elevation MAY be
included as an optional third element".
EXAMPLE: { "type": "Feature", "geometry": { "type": "Point", "coordinates": [12.4924, 41.8902, 50] } }
Again in GeoJSON [2], "An OPTIONAL third-position element SHALL be the height in meters above or below the WGS
84 reference ellipsoid. In the absence of elevation values, applications sensitive to height or depth SHOULD interpret
positions as being at local ground or sea level".
For the components of the utilities' networks, the ETSI SAREF ontology (https://saref.etsi.org) provides the necessary
complement to the NGSI-LD API and could be extended when needed.
Due to the large scale of these networks and the needed precision, geo-localized coordinates are normally used, and the
NGSI-LD Cross Domain Information Model [5], as well as the NGSI-LD API [1], answer the need, provided that a
CRS is added to them, as specified in clause 6.2.
Recommendation: add a CRS property to the Cross Domain Information Model [5] and API [1].
4.3 Disaster and emergency
4.3.0 Foreword
The ability to share data with precise geospatial references in 2D and 3D with higher refresh intervals is important.
Because disasters and emergencies always trigger a "crisis mode", it may be useful that the requirements on
subscriptions related to crisis events can be defined and tested in advance and be ready to be instantiated in the context
broker when an alert is raised.
The "isActive" member of a subscription enables this capability, as described in Table 1, which is extracted from
Table 5.2.12-1 of ETSI GS CIM 009 [1].
Table 1: isActive member description
isActive Boolean true by default 0.1 Allows clients to temporarily pause
the subscription by making it
inactive. true indicates that the
Subscription is under operation.
false indicates that the
subscription is paused, and
notifications shall not be delivered.

The description in Table 1 might be clearer to the users of the NGSI-LD API if the fact that a paused subscription does
not execute any queries is added in the description, for example by changing it as follows:
Allows clients to temporarily pause the subscription by making it inactive. true indicates that the Subscription is under
operation. false indicates that the subscription is paused, associated queries shall not be executed, and notifications
shall not be delivered.
More importantly, in Table 5.2.14.1-1 of ETSI GS CIM 009 [1], NotificationParams.endpoint cardinality is "1",
indicating that the notification is sent to only one endpoint. The proposal is to change it to "1.*" to dispatch the same
information to various endpoints, instead.
ETSI
10 ETSI GS CIM 050 V1.1.1 (2024-11)
Recommendation: further study the opportunity to modify the NotificationParams.endpoint cardinality from "1" to
"1.*" in Table 5.2.14.1-1 of the NGSI-LD API [1].
4.3.1 Challenge of defining regions of interest
In order to define a location, cities are using both geometries with precisely defined geospatial coordinates and/or
geographical names. The OGC standards, allow Locations to be defined by a geometry object like a point, a polygon, a
polyline, a set geometry, but also with a name and a URI [i.1] which identify the Location, as shown in Table 2,
extracted from section 7.12 of release 3.0.0 of GeoDCAT-AP [i.16].
In ETSI GS CIM 009 [1] and ETSI GS CIM 006 [5] the geographic location (GeoProperty) is defined as a coordinate-
based location. It is useful, to meet the requirements of the smart cities, to add support to "named locations", similarly to
what is specified by the GeoDCAT.
Table 2: Location entity of GeoDCAT
(source [i.16] version 2.0.0)
This property MAY be used to
+gazetteer skos:inScheme skos:ConceptScheme specify the gazetteer to which the 0.1
Location belongs.
This property contains the
geographic identifier for the
+geographic
dct:identifier rdfs:Literal Location, e.g. the URI or other 0.n
identifier
unique identifier in the context of
the relevant gazetteer.
This property contains a
preferred label of the Location.
+geographic This property can be repeated for
skos:prefLabel rdfs:Literal 0.n
name parallel language versions of the
label - see § 9. Accessibility and
Multilingual Aspects.
rdfs:Literal typed This property associates any
geometry locn:geometry as gsp:wktLiteral or resource with the corresponding 0.1
gsp:gmlLiteral geometry.
The GeoDCAT-AP [i.16] does not say anything about the simultaneous usage of geometry, bbox, centroid or names to
define the location, whereas the DCAT-AP-JRC [i.17] specifies that the Location has to be defined either by a name or
by a geometry, but not both.
For NGSI-LD the choice of following the DCAT-AP-JRC [i.17] recommendation of using either names or geometry is
to be evaluated with the NGSI-LD philosophy. Allowing simultaneous usage of the names and the geometries will
simplify the processing of data as there is no need for an extra query to a geoname server to get the geometry associated
with the identifier.
It can be noted that, as proposed in ETSI GR CIM 048 [i.18], attaching an identifier to the location may let infer that
Location becomes an Entity. However, this identifier being "optional", it makes sense to keep location as a Property in
NGSI-LD and call this identifier "geographic-identifier".
There are 4 options to implement named locations:
• Domains are free to define Location as an entity and include named location members in addition to NGSI-LD
location GeoProperty in the entity. This was the initial proposal from the DCAT mapping:
- PRO: no impact on NGSI-LD API.
- CONS: different domains will end up having different ways to specify named locations.
ETSI
11 ETSI GS CIM 050 V1.1.1 (2024-11)
• The NGSI-LD Cross Domain defines a Location entity which includes named location in addition to the
location GeoProperty:
- PRO: minimal impact on NGSI-LD API, no change on the location GeoProperty.
- CONS: it adds an Entity in the Cross Domain when the philosophy seems to limit Entities specified by
the API.
The geographic identifier in the GeoDCAT is an optional member, which means that the Entity will have
2 identifiers: a mandatory ID and an optional geographicIdentifier.
• The NGSI-LD location GeoProperty is modified to include an optional named location and have the
coordinates-based GeoProperty optional. (This option can be used for the DCAT mapping):
- PRO: can be re-used by all domains.
- CONS: will have an impact on the API as the geometry becomes optional.
• New Properties "geographicIdentifier" and "gazetteer" shown in Table 3 and "geographicName" shown in
• Table 4 are added to the Cross Domain Ontology [5], and they are used from API [1] as Properties of an
Entity:
- PRO: can be re-used by all domains.
- CONS: generates a more complex mapping for the DCAT to NGSI-LD.
Table 3: geographicIdentifier and gazetteer Properties description
geographicIdentifier String 0.n This property contains the
geographic identifier for the
Location, e.g. the URI or
other unique identifier in the
context of the relevant
gazetteer.
gazetteer String Valid URI 0.1 This property is a sub
property which MAY be
used to specify the
gazetteer to which the
geographicIdentifier
belongs.
Table 4: geographicName Property description
geographicName LanguageMap The EU Vocabularies 0.n This property contains a
Name Authority Lists preferred label of the
shall be used for Location. This property can
continents, countries be repeated for parallel
and places that are in language versions of the
those lists; if a particular label.
location is not in one of
the mentioned Named
Authority Lists,
Geonames URIs shall
be used.
Recommendation: add support in ETSI GS CIM 009 [1] for a named location with 2 properties geographicIdentifier and
geographicName.
4.4 The need to work at different scales
In order to accommodate the ability to manage different scales in the representation of geometric information, in a map
application for example, the recommendation is to use the concept of "Level of detail" as defined in CityGML [i.8] with
a JSON implementation. See clause 6.4.
ETSI
12 ETSI GS CIM 050 V1.1.1 (2024-11)
Another topic related to scale is that when one wants to represent
...