Skip to content

Commit 82b536b

Browse files
committed
Rewrote many parts, removed links, collection-level data as foreign members to FeatureCollection
1 parent ce4dcfd commit 82b536b

File tree

8 files changed

+199
-319
lines changed

8 files changed

+199
-319
lines changed

CHANGELOG.md

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -17,16 +17,15 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
1717

1818
- Switched from v0.1.0 to v0.2.0 of the schema language
1919
- Renamed `fiboa_extensions` to `schemas`
20+
- Schemas must be valid HTTP(S) URLs
2021
- GeoJSON: Switched `contentEncoding` for data type `binary` from `binary` to `base64`
21-
22-
### Deprecated
23-
24-
- ...
22+
- GeoJSON FeatureCollection: Collection-level data is provided at the top-level, not in a `fiboa` property
2523

2624
### Removed
2725

2826
- Value `administrative` was removed from `determination_method` in favor of the new property `category`
2927
- `fiboa_version` in favor of adding the schema URL of the specification to `schemas`.
28+
- GeoJSON Feature: `links` property
3029

3130
### Fixed
3231

core/README.md

Lines changed: 76 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -1,39 +1,66 @@
1-
# Core Specification
1+
# Core Specification <!-- omit in toc -->
22

3-
This specification describes the core data and metadata properties for both at the
4-
Collection and Feature level.
3+
This specification describes the core data and metadata properties that describe a fiboa Feature.
4+
The specification doesn't distinguish between collection-level and feature-level properties,
5+
common definitions are shared across these levels.
56

67
- A Collection refers to a group of one or more features.
78
- A Feature is a single field geometry with additional properties.
89

9-
> [!NOTE]
10-
> The Core Specification is still work in progress. Feedback is welcome!
11-
1210
- **Schema:** <https://fiboa.github.io/specification/v0.2.0/schema.yaml>
1311

14-
## Schema
12+
## Table of Contents <!-- omit in toc -->
1513

16-
The data types in the following document are defined in
17-
[fiboa Schema](https://github.com/fiboa/schema), v0.2.0.
14+
- [General Properties](#general-properties)
15+
- [schemas](#schemas)
16+
- [id](#id)
17+
- [collection](#collection)
18+
- [category](#category)
19+
- [Spatial Properties](#spatial-properties)
20+
- [area / perimeter](#area--perimeter)
21+
- [Determination Properties](#determination-properties)
22+
- [determination\_datetime](#determination_datetime)
23+
- [determination\_method](#determination_method)
24+
- [Schema Language](#schema-language)
1825

19-
fiboa Schema defines a (limited) set of data types and a vocabulary to express
20-
additional constraints for these data types.
21-
This allows to define a clear mapping between the core specification and its encodings.
26+
## General Properties
27+
28+
| Property Name | Data Type | Description |
29+
| ------------- | -------------- | ----------- |
30+
| schemas | array\<string> | **REQUIRED.** A list of schemas the collection implements. |
31+
| id | string | **REQUIRED.** An identifier for the field. |
32+
| collection | string | The identifier of the parent collection. |
33+
| category | array\<string> | A set of categories the field boundary belongs to. |
2234

23-
- [Data types](https://github.com/fiboa/schema/blob/v0.2.0/datatypes.md)
24-
- [Vocabulary](https://github.com/fiboa/schema/blob/v0.2.0/README.md#vocabulary)
35+
### schemas
2536

26-
## Collections
37+
The schemas the collection implements.
38+
Each schema must be a valid HTTP(S) URLs to an existing YAML files compliant to fiboa Schema.
39+
The schema for this specification (see above) is required to be provided.
40+
41+
Each `collection` must have a single set of applicable schemas.
42+
43+
The schema URI listed above is required to be present in the `schemas` array.
44+
45+
### id
2746

28-
A Collection is a group of one or more features with a unique identifier (see property `collection`).
47+
It must be unique per collection, i.e. `collection` and `id` form a unique identifier.
2948

30-
Each collection must have a single set of applicable schemas.
49+
### collection
3150

32-
Any property that consists of the same value across all features can be de-duplicated to the collection-level
33-
if more than two features are available for the collection.
51+
A collection is a group of one or more features with a unique identifier, stored in the `collection` property.
52+
53+
The collection identifier is usually only needed for merged datasets and it is **required** in this case.
54+
Implementations may create collection identifiers if datasets that don't provide a collection identifer are getting merged.
55+
A validatior can't know whether the `collection` property is required, the data providers or tooling must handle this,
56+
i.e. if data from two different sources is merged, a `collection` property with distinct values must be provided.
57+
This ensures unique IDs through the combination of the properties `id` and `collection`.
58+
59+
Encodings may support to store properties that consists of the same value across all features at the collection-level.
60+
This de-duplicates data for more efficient resource usage, but only applies if more than two features are available for the collection.
3461
The specific location and behaviour of collection-level data is specified in the encoding-specific specifications.
3562

36-
Example:
63+
**Example:**
3764

3865
You have two different field boundary datasets named `abc` (CC-0 licensed) and `xyz` (CC-BY-4.0 licensed).
3966
If you store the datasets separately, you can store the license in the collection-level data
@@ -42,23 +69,9 @@ Once you merged the two datasets, you must ensure that a unique identifier for t
4269
(here: `abc` and `xyz`) so that IDs are unique.
4370
Additionally, you have to add the license property on the feature-level as the licenses are now twofold.
4471

45-
## General Properties
46-
47-
| Property Name | Data Type | Description |
48-
| ------------- | -------------- | ----------- |
49-
| schemas | array\<string> | **REQUIRED.** A list of URLs to schemas the collection implements. |
50-
| id | string | **REQUIRED.** A unique identifier for the field. It must be unique per collection, i.e. `collection` and `id` form a unique identifier. |
51-
| collection | string | The identifier of the parent collection. |
52-
| category | array\<string> | A set of categories the field boundary belongs to. |
72+
### category
5373

54-
**schemas:** The schemas the collection implements. Must be URLs to the schema YAML files.
55-
The schema for this specification (see above) is required to be provided.
56-
57-
**collection:** The collection identifier is usually only needed for merged datasets and it is **required** in this case.
58-
A validatior can't check whether the `collection` property is required, the data providers or tooling must ensure that if data from two different sources are merged that a `collection` property with distinct values is provided.
59-
Otherwise, IDs may conflict or extension requirements might not be fulfilled and validation could fail.
60-
61-
**category:** Choose any (unique) combination of the following values:
74+
Choose any (unique) combination of the following values:
6275

6376
- `conceptual`: This boundary represents how the grower thinks of a field, and what they would share with service
6477
providers to allocate information at the highest level of the field concept within their operation.
@@ -81,29 +94,36 @@ The categories are based on the [definitions of the AgGateway initiative](https:
8194
| area | float | Area of the field, in hectares. Must be > 0 and <= 100,000. |
8295
| perimeter | float | Perimeter of the field, in meters. Must be > 0 and <= 125,000. |
8396

84-
**area/perimeter:** These are derived attributes from the geometry itself,
97+
### area / perimeter
98+
99+
These are derived attributes from the geometry itself,
85100
and must match the geometry's area/perimeter. If they do not match then the
86101
geometry should be considered canonical.
87102
Validators may flag the value as invalid if it exceeds a certain threshold.
88103

89104
## Determination Properties
90105

91-
| Property Name | Data Type | Description |
92-
| ---------------------- | --------- | ------------------------------------------------------------ |
93-
| determination_method | string | The boundary creation method, one of the values below. |
94-
| determination_datetime | datetime | The last timestamp at which the field did exist and was observed, in UTC. |
106+
| Property Name | Data Type | Description |
107+
| ---------------------- | --------- | ----------- |
108+
| determination_method | string | The boundary creation method, one of the values below. |
109+
| determination_datetime | datetime | The last timestamp at which the field did exist and was observed. |
95110
| determination_details | string | Further details about the determination, especially the methodology. |
96111

97-
**determination_datetime**: In case the source of the information is an
98-
interval or a set of timestamps, use the end.
112+
### determination_datetime
113+
114+
The last timestamp at which the field did exist and was observed, provided in the UTC timezone.
115+
116+
In case the source of the information is an interval or a set of timestamps, use the end.
99117
For example, for ML you'd use the timestamp of the last image and not the
100118
timestamp of the actual execution.
101119

102120
> [!NOTE]
103121
> We define more temporal properties in the
104122
> [timestamps extension](https://github.com/fiboa/timestamps).
105123
106-
**determination_method**: Must be one of the following values:
124+
### determination_method
125+
126+
The determination method must be one of the following values:
107127

108128
- `manual`: Hand created from imagery, e.g. using a tool to point and click on a map.
109129
- `surveyed`: Determined through a professional land survey measuring the actual distances and angles on the ground.
@@ -114,3 +134,15 @@ timestamp of the actual execution.
114134

115135
The determination methods are based on the definitions of the [AgGateway initiative - WG17](https://aggateway.org/).
116136
The specific values have [not been published yet](https://github.com/fiboa/specification/issues/31).
137+
138+
## Schema Language
139+
140+
The schema language used for fiboa is [fiboa Schema](https://github.com/fiboa/schema), version 0.2.0.
141+
142+
The data types in the tables above are defined in the document
143+
[Data Types](https://github.com/fiboa/schema/blob/v0.2.0/datatypes.md).
144+
145+
fiboa Schema defines a (limited) set of data types and a
146+
[vocabulary](https://github.com/fiboa/schema/blob/v0.2.0/README.md#vocabulary)
147+
to express additional constraints for these data types.
148+
This allows to define a clear mapping between the core specification and its encodings.

core/schema/schema.yaml

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ properties:
99
items:
1010
type: string
1111
format: uri
12+
pattern: ^https?://
1213
contains:
1314
type: string
1415
enum:

geojson/README.md

Lines changed: 45 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -1,65 +1,73 @@
11
# GeoJSON Encoding Specification
22

3-
The GeoJSON encoding defines how field boundaries compliant to fiboa must be published.
4-
The generic GeoJSON format is defined in
5-
[IETF RFC 7946](https://datatracker.ietf.org/doc/html/rfc7946).
3+
The GeoJSON encoding defines to encode field boundaries compliant to fiboa as
4+
GeoJSON as defined in [IETF RFC7946](https://datatracker.ietf.org/doc/html/rfc7946).
65

7-
> [!NOTE]
8-
> The GeoJSON encoding is still work in progress. Feedback is welcome!
6+
A single fiboa Feature must be encoded as a GeoJSON [`Feature`](#feature).
7+
Multiple fiboa Featurs should be provided as a GeoJSON [`FeatureCollection`](#featurecollection).
8+
Other GeoJSON types are not allowed.
99

10-
- **[Examples](examples/):**
11-
1. [as a FeatureCollection](examples/featurecollection/features.json)
12-
2. [as individual Features with a dedicated Collection](examples/individual-features/)
13-
- **[Datatype mapping](datatypes.md)**
10+
Related documents:
1411

15-
## FeatureCollection
16-
17-
A FeatureCollection may have a top-level property named `fiboa` to contain all collection-level data.
18-
If present, it contains all properties that are common across the features
19-
and the features shall not contain those properties.
20-
Validation must ensure that the collection-level properties are taken into account.
21-
All features in a FeatureCollection must be fiboa-compliant.
22-
23-
The following properties can't be collection-level properties:
24-
25-
- `id`
26-
- `geometry`
27-
- `bbox`
12+
- [Examples](examples/)
13+
- [Datatype mapping](datatypes.md)
2814

2915
## Feature
3016

31-
Each [fiboa Feature](../core/README.md#features) must be a valid
17+
- Example: [individual features](examples/individual-features/)
18+
19+
Each [fiboa Feature](../core/README.md) must be a valid
3220
[GeoJSON Feature](https://datatracker.ietf.org/doc/html/rfc7946#section-3.2).
3321

3422
The following properties are defined for a GeoJSON Feature (at the top-level of the object):
3523

36-
| Property Name | Data Type | Description |
37-
| ------------- | ------------------- | ------------------------------------------------------------ |
38-
| id | string | **REQUIRED.** See [id](../core/README.md#general-properties) in the core specification, must not be a `number` |
39-
| type | string | **REQUIRED.** The GeoJSON type, must be: `Feature` |
24+
| Property Name | Data Type | Description |
25+
| ------------- | ------------------- | ----------- |
26+
| id | string | **REQUIRED.** See [id](../core/README.md#id) in the core specification, must not be a `number` |
27+
| type | string | **REQUIRED.** The GeoJSON type, must be: `Feature` |
4028
| geometry | object | **REQUIRED.** A [GeoJSON Geometry Object](https://datatracker.ietf.org/doc/html/rfc7946#section-3.1), must not be `null` |
4129
| bbox | array\<number> | A [GeoJSON Bounding Box](https://datatracker.ietf.org/doc/html/rfc7946#section-5) |
4230
| properties | object | An object with all additional properties (see [`properties`](#properties)) |
43-
| links | array\<Link Object> | A list of links (see [`links`](#links)) |
31+
32+
The mapping between the Parquet data types and the fiboa data types, can be found in the
33+
[data type mapping](datatypes.md).
4434

4535
> [!IMPORTANT]
4636
> RFC 7946 doesn't support a property named `crs`, which was only available in an earlier version of GeoJSON (2008).
4737
> The CRS of the GeoJSON geometry and bbox must be WGS 84 / OGC CRS 84,
48-
> see the [RFC 7946, chapter 4](https://datatracker.ietf.org/doc/html/rfc7946#section-4) for details.
38+
> see the [RFC 7946, chapter 4](https://datatracker.ietf.org/doc/html/rfc7946#section-4) for details.
4939
50-
### `properties`
40+
[Collection-level](../core/README.md#collection) data is not supported.
41+
All properties are provides in the JSON object with the key [`properties`](#properties).
42+
43+
### properties
5144

5245
Must include any property that is required by the fiboa core specification.
5346
May include any additional property.
5447
All properties defined by the core specification (except for `id`, `geometry` and `bbox`) or extensions should be provided here.
5548

56-
### `links`
49+
## FeatureCollection
50+
51+
- Example: [a feature collection](examples/featurecollection/features.json)
52+
53+
All features in a GeoJSON FeatureCollection must be fiboa-compliant.
54+
55+
Properties can also be stored at the [collection-level](../core/README.md#collection)
56+
if all values for a specific property have the same value in all features.
57+
This de-duplicates data for more efficient resource usage.
58+
All properties are stored on the top-level of the FeatureCollection object as
59+
[foreign members](https://datatracker.ietf.org/doc/html/rfc7946#section-6.1).
60+
The individual features shall not contain any properties that are stored at the collection-level.
61+
Validation must ensure that the collection-level properties are taken into account.
62+
63+
The following properties in Features can't be collection-level properties:
5764

58-
An array of links where each link conforms to the
59-
[Hyperlink Schema](http://schemas.opengis.net/ogcapi/common/part1/1.0/openapi/schemas/link.yaml)
60-
defined in
61-
[OGC API - Common - Part 1](https://docs.ogc.org/is/19-072/19-072.html#_11b9b4f7-42fc-413a-b63a-e7fb060b5e4b).
65+
- `id`
66+
- `geometry`
67+
- `bbox`
6268

63-
The following relation types are commonly used:
69+
Properties with the following names can#t be moved to the collection-level due to conflicts with the
70+
FeatureCollection properties defined by GeoJSON:
6471

65-
- `self`: Absolute link to the GeoJSON file itself.
72+
- `features`
73+
- `type`

0 commit comments

Comments
 (0)