Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

### Added

- PMTiles
- New property `wms:transparent` for WMS
- Roles to specify the layer type, visibility and default layers.

### Changed

Expand Down
30 changes: 29 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Important resources in this extension:

This extension only extends the [Link Object](https://github.com/radiantearth/stac-spec/tree/master/item-spec/item-spec.md#link-object)
used in all STAC entities (Catalogs, Collections, Items). It requires specific relation types to be set for the `rel` field in the
Link Object.
Link Object and also allows to set specific `roles`.

An attribution field is not defined as part of this extension, but it is RECOMMENDED to provide an attribution
in the top-level object of the document (in the `properties` for Items) via the `attribution` field as defined in
Expand Down Expand Up @@ -144,8 +144,36 @@ The following field applies to multiple types of web mapping services:

| Field Name | Type | Description |
| ------------ | --------- | ----------- |
| roles | \[string] | A list of roles, see the list below. |
| href:servers | \[string] | A list of replacement values for `{s}` in `href`s. |

#### roles

Several roles can be assigned that provide an indicator for the web map library how to handle the link.

**One of** the following roles may bet set to describe the type of layer.
If no role is provided, `data` is assumed to be the default.

| Role | Description |
| ------- | ----------- |
| basemap | A basemap. |
| overlay | An overlay with transparent background to show on top of basemaps. |
| data | A layer with the actual data to show on top of the other layer types. |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you provide an example of a "layer sandwich" including base, overlay and data? In general, I have the feeling that in some cases the overlay could be on top of the data layer. A basic example is Google Maps with its data layers (Public transit, Traffic etc.) which shows between the background (Default, Satellite or Terrain) and the overlay (street/POI names).
Or would you consider the e.g. traffic data as base layer on top of the other base layer and no data layer? 🤔

Copy link
Contributor Author

@m-mohr m-mohr Feb 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In your example the traffic/public transit is a second overlay, I think. Alternatively, we could argue that both belong to data.

Generally, this is not meant to cover all edge cases, but the most common ones that are supported by mapping libraries by default. Depending on the usecase, you may choose different layer types.


**One of** the following roles may be used to indicate whether a layer should be shown by default.
If none of the roles is provided, it's up to the discretion of the implementation to choose.

| Role | Description |
| --------- | ----------- |
| visible | Make the layer *visible* by default. |
| invisible | Make the layer *invisible* by default. |

Additionally, the following role may be used:

| Role | Description |
| ------- | ----------- |
| default | If multiple layers with the same type are visible, specify which one should be shown by default. |

#### href:servers

This field is used to specify a set of URLs for a web mapping library so that requests can be sent to multiple servers,
Expand Down