Geometry draft value type

This is not an entity type but a structure used as the value of an attribute.

A GeoJSON geometry (RFC 7946) as the value of a GeoProperty such as location: Point, LineString, Polygon, their multi forms (MultiPoint, MultiLineString, MultiPolygon), or a GeometryCollection of these. Positions are longitude, latitude and optional altitude, in WGS 84. A model may narrow the allowed types, for example to Point only.

Japanese name	ジオメトリ
IRI	https://datamodels.jp/ns/common/Geometry
@context	https://datamodels.jp/context/common/v1.jsonld (alias, latest compatible version) https://datamodels.jp/context/common/v1.0.0.jsonld (this version, immutable)
JSON Schema	/schema/common/Geometry/v1.json /schema/common/Geometry/v1.0.0.json
Examples	example.json
Source	github.com/geolonia/datamodels

Usage

"location": {
  "$ref": "https://datamodels.jp/schema/common/Geometry/v1.0.0.json",
  "x-ngsi": { "type": "GeoProperty", "model": "https://datamodels.jp/ns/common/Geometry" },
  "x-iri": "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.8.jsonld#location"
}

Example (key-values)

The examples are a fictional scenario (heavy rain in Chiyoda, Tokyo). Place names and codes are real; the events, people and teams are invented. See writing examples.

{
  "type": "Polygon",
  "coordinates": [
    [
      [
        139.7515,
        35.693
      ],
      [
        139.755,
        35.693
      ],
      [
        139.755,
        35.6955
      ],
      [
        139.7515,
        35.6955
      ],
      [
        139.7515,
        35.693
      ]
    ]
  ]
}

Notes

• A value type, not an entity type. Use it as the value of the core location GeoProperty (or another GeoProperty) and reference the schema with $ref from an entity schema. The member names (type, coordinates, bbox) and the geometry types (Point, Polygon and so on) are terms of the NGSI-LD core context and expand to the GeoJSON-LD vocabulary; the catalog mints only the class for any of these geometries.
• Stricter than RFC 7946 alone: a position has two or three numbers, and a multi-geometry, a Polygon or a GeometryCollection has at least one member. A model narrows the allowed types with a type constraint next to the $ref, as Attachment does for Point.
• RFC 7946 §3.1.6 requires every linear ring to close (first and last position identical). JSON Schema cannot express this; the catalog's validator checks the rings of every example in the catalog, and consumers should check instances with a GeoJSON-aware library.
• The class is minted (https://datamodels.jp/ns/common/Geometry) because the GeoJSON-LD vocabulary (https://purl.org/geojson/vocab#) defines the individual geometry types but no class for a geometry in general. OGC's Simple Features vocabulary (http://www.opengis.net/ont/sf#Geometry) has such a class, but GeoJSON values in NGSI-LD expand to the GeoJSON-LD types, not to Simple Features.
• Upstream considered (2026-09-25): the GeoJSON schemas at geojson.org (JSON Schema draft-07 while this catalog uses 2020-12; GeometryCollection in a separate file; unversioned URLs; empty coordinate arrays accepted) and Smart Data Models Location-Commons in common-schema.json (six types without GeometryCollection; defines a whole location property rather than a reusable geometry; published on master only). Neither can be referenced as it is; this schema follows the same RFC 7946 structure.
• The NGSI-LD core context (v1.8) defines coordinates and bbox but not geometries, so in JSON-LD processing a GeometryCollection's geometries expand to the core context's default vocabulary, and a collection with a single member compacts back to an object instead of an array. Brokers that store GeoJSON as it is are not affected.

Model content on this page is licensed under CC BY 4.0. LICENSE-CONTENT