You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- JSON schemas for eodash catalog configs for purposes of validation - matching [eodash catalog wiki entries](https://github.com/eodash/eodash_catalog/wiki)
The basic process content submission is expected to be done through configuration and content files via a version control system such as git. Depending on how the eodash ecosystem is integrated into a platform it is possible that abstraction layers, such as custom user interfaces (such as Content Management Systems) or helper tools are build on top to help users of the platform.
An eodash instance expects to load its content from a STAC catalog. This catalog can be generated using the [eodash_catalog](https://github.com/eodash/eodash_catalog). As can be seen in the [catalog wiki](https://github.com/eodash/eodash_catalog/wiki/Resource) there are multiple services supported.
4
4
5
5
We consider eodash to be a data integrator, so we find a "serverless" approach for data integration to be a great opportunity to not require more complex setups when wanting to share your data, apart from making them reachable online. For this we want to give explanations and examples of how this can be done for raster and vector data.
6
-
Currently we support Cloud Optimized GeoTIFFs (COGs) for raster and GeoJSON files for vector data. We want to support cloud optimized formats for vector data as soon as possible.
6
+
Currently we support Cloud Optimized GeoTIFFs (COGs) for raster and GeoJSON or FlatGeoBuf files for vector data.
7
+
8
+
For all three types of files, returned [CORS headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS) on the server side need to be correctly set up in order to let the eodash in a browser access them directly from a different domain than eodash is usually running on. You can use [following CORS validator](https://cors-test.codehappy.dev/) - (not affiliated with eodash project, use at your own discretion) for your resources to check if the response CORS headers are set up correctly for access from the domain where eodash is/will be hosted.
7
9
8
10
For both data types we wanted to introduce a shared language that gives the user the tools to fully describe how they should be rendered and interacted with. This is achieved by using a style JSON configuration file that utilizes the languages of [OpenLayers flat style](https://openlayers.org/en/latest/apidoc/module-ol_style_flat.html) as well as [JSON Form](https://github.com/jsonform/jsonform/wiki#using-json-schema-to-describe-your-data-model) definition language as extended by the EOxElement [eox-jsonform](https://eox-a.github.io/EOxElements/?path=/docs/elements-eox-jsonform--docs).
9
11
The style reference for STAC as a possible extension is being discussed [here](https://github.com/radiantearth/stac-spec/issues/1284). We currently take the proposed 3B approach.
10
12
11
-
Following is the catalog structure that would be generated when using the catalog creation helper tool.
13
+
Following is the catalog structure that would be generated when using the [eodash_catalog](https://github.com/eodash/eodash_catalog) tool.
Datasets can be referenced as assets within one item (i.e. TimeEntry) and then utilized as part of the style. Let's look at some examples.
17
+
Datasets can be referenced as assets within one item (i.e. TimeEntry) and then utilized as part of the style.
16
18
17
19
## Vector data
18
20
19
-
Here is an example configuration for the catalog tool to add a geojson:
21
+
Here is an example configuration for the catalog tool to add a GeoJSON file:
20
22
21
-
```yaml
22
-
Name: example_collection
23
-
Title: Example collection for vector data
24
-
EodashIdentifier: exmpl1
25
-
Description: This can be **markdown** text
26
-
Resources:
27
-
- Name: GeoJSON source
28
-
Style: https://location.of/vector_style.json
29
-
Bbox: [9.27, 46.2, 17.3, 49.2]
30
-
TimeEntries:
31
-
- Time: "2024"
32
-
Assets:
33
-
- Identifier: vector_data
34
-
File: https://location.of/file.json
23
+
```json
24
+
{
25
+
"Name": "example_collection",
26
+
"Title": "Example collection for vector data",
27
+
"EodashIdentifier": "exmpl1",
28
+
"Description": "This can be **markdown** text",
29
+
"Resources": [
30
+
{
31
+
"Name": "GeoJSON source",
32
+
"Style": "https://location.of/vector_style.json",
33
+
"Bbox": [
34
+
9.27,
35
+
46.2,
36
+
17.3,
37
+
49.2
38
+
],
39
+
"TimeEntries": [
40
+
{
41
+
"Time": "2024",
42
+
"Assets": [
43
+
{
44
+
"Identifier": "vector_data",
45
+
"File": "https://location.of/file.json"
46
+
}
47
+
]
48
+
}
49
+
]
50
+
}
51
+
]
52
+
}
35
53
36
54
```
37
55
38
-
Let's now look at the style definition options. Firstly we can explore the [flat style definition](https://openlayers.org/en/latest/apidoc/module-ol_style_flat.html) of OpenLayers. Here is a very basic example of how to style some things:
56
+
([FlatGeobuf resource](https://github.com/eodash/eodash_catalog/wiki/Resource#raw-sources) would just have a different Resource Name)
57
+
58
+
Here is a very basic example of how to style vector data:
39
59
```json
40
60
{
41
61
"fill-color": "red",
@@ -46,140 +66,75 @@ Let's now look at the style definition options. Firstly we can explore the [flat
46
66
47
67
48
68
69
+
For more possibilities of vector data styling, description of parameters and options, please see dedicated [styling guide](./styling#vector-styling).
49
70
50
-
In order to define interaction options for the user this can be extended with variables, combined with JSON Form definition. To continue the example, let's say, we would like the user to be able to change the stroke-width with a slider, we can extend the style file like this:
51
-
```json
71
+
## Raster data
72
+
73
+
Here is an example configuration for the catalog tool to add two single band COGs.
74
+
75
+
```yaml
52
76
{
53
-
"variables": {
54
-
"strokeWidth": 1
55
-
},
56
-
"fill-color": "red",
57
-
"stroke-color": "black",
58
-
"stroke-width": ["var", "strokeWidth"],
59
-
"jsonform": {
60
-
"type": "object",
61
-
"title": "Data configuration",
62
-
"properties": {
63
-
"strokeWidth": {
64
-
"type": "number",
65
-
"minimum": 0,
66
-
"maximum": 10,
67
-
"format": "range",
68
-
"default": 0
69
-
}
77
+
"Name": "example_collection",
78
+
"Title": "Example collection for raster data",
79
+
"EodashIdentifier": "exmpl2",
80
+
"Description": "This can be **markdown** text",
81
+
"Resources": [
82
+
{
83
+
"Name": "COG source",
84
+
"Style": "https://location.of/raster_style.json",
85
+
"Bbox": [
86
+
9.27,
87
+
46.2,
88
+
17.3,
89
+
49.2
90
+
],
91
+
"TimeEntries": [
92
+
{
93
+
"Time": "2024",
94
+
"Assets": [
95
+
{
96
+
"Identifier": "cog1",
97
+
"File": "https://location.of/cogfile1.tiff"
98
+
},
99
+
{
100
+
"Identifier": "cog2",
101
+
"File": "https://location.of/cogfile2.tiff"
102
+
}
103
+
]
70
104
}
105
+
]
71
106
}
107
+
]
72
108
}
73
-
```
74
-
75
-
76
-
Taking these concepts into account, one can extend the style to use also the `get` functionality of flat styles to access feature properties of the geoJSON as well as [encoded expressions](https://openlayers.org/en/latest/apidoc/module-ol_expr_expression.html#~EncodedExpression) truly custom and interactive styles can be created.
77
109
78
-
## Raster data
110
+
```
79
111
80
-
Here is an example configuration for the catalog tool to add a some cloud optimized geotiffs (COGs):
112
+
In eodash and OpenLayers, each COG contributes with all it's indexed bands in a sequence to the rendering and needs to be accounted for in the style definition.
81
113
82
-
```yaml
83
-
Name: example_collection
84
-
Title: Example collection for raster data
85
-
EodashIdentifier: exmpl2
86
-
Description: This can be **markdown** text
87
-
Resources:
88
-
- Name: COG source
89
-
Style: https://location.of/raster_style.json
90
-
Bbox: [9.27, 46.2, 17.3, 49.2]
91
-
TimeEntries:
92
-
- Time: "2024"
93
-
Assets:
94
-
- Identifier: cog1
95
-
File: https://location.of/cogfile1.tiff
96
-
- Identifier: cog2
97
-
File: https://location.of/cogfile2.tiff
98
-
99
-
```
114
+
In this case, the `cogfile1.tiff` would be used as a `[band, 1]` and `cogfile2.tiff` as `[band, 2]`.
100
115
101
116
The style configuration for raster data functions in exactly the same way as the one described for vector data, but only uses the `color` attribute do define how your raster data is rendered.
102
117
103
-
Here is a more elaborate example which shows the use of `["band", 1]` to access values from the COGs, as well as normalizing the data to 0-1 values, and then applying a interpolated 16 value viridis colormap. The vmin and vmax variables are used to do the normalization allowing dynamic color range adaptation in the eodash instance. It uses band 2, to filter what data gets rendered, if the case does not apply, it renders the corresponding pixel as transparent.
104
-
118
+
Here is a very basic example of grayscale rendering of raster values from 0 to 400 and manually filtering `No Data areas` (value 0) as transparent:
Here is how that translates to a visualization in the eodash instance:
182
137
183
-
138
+
For more possibilities of raster data styling, description of parameters and options, please see dedicated [styling guide](./styling#raster-styling).
184
139
185
140
This covers the basics for "serverless" data integration. Integration of datasets provided through services do not use a style file, each endpoint provides their own configuration options which can be defined in the data definition configuration file. For more information please go to the [resource section](https://github.com/eodash/eodash_catalog/wiki/Resource) of the catalog wiki.
0 commit comments