Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update non-webby-ogc-standards.md #1121

Merged
merged 1 commit into from
Apr 11, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
35 changes: 25 additions & 10 deletions roadmap/non-webby-ogc-standards.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,84 +4,95 @@ The following is a list of OGC standards which are well-deployed in the geospati

(There are many more OGC standards, but most of these are not meant to be used on the web directly. In other words, not all standards need to be "Webby". Not listed are, for example, standards for data exchange by download/import/export or standards that are conceptual models.)

Criteria we use for a standard to be considered *Webby*:
- *The standard fully supports and follows the [fundamental concepts of current web architecture][1]*. This includes the use of URIs for identification; interaction using HTTP(S), content negotiation, and linking to other resources, including to secondary resources; and formats with agreed syntax and semantics. A representation of a resource is sent together with metadata, identifying the content-type.
- *The standard is easy and simple enough for non-experts in geospatial data and geospatial information systems to understand and use*. Complexity in geospatial standards often stems from the fact that they cover a wide range of use cases, many of which are not required by non-experts.
- *The standard is web-developer-friendly*, i.e. meets the expectations of many Web developers, for example by using encodings that are common on the Web, using HTTP verbs, etc. Note that this is a different criterium from the previous one; for example, it's about developers preferring encodings such as JSON to XML/GML. Note: what's 'developer-friendly' can be a trend sensitive thing.
Criteria we use for a standard to be considered *Webby*:

## Web Map Service (WMS)
| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Map Service (WMS) | ? | ? | no |
- *`WWW-aligned:` The standard fully supports and follows the [fundamental concepts of current web architecture][1]*. This includes the use of URIs for identification; interaction using HTTP(S), content negotiation, and linking to other resources, including to secondary resources; and formats with agreed syntax and semantics. A representation of a resource is sent together with metadata, identifying the content-type.
- *`Accessible:` The standard is easy and simple enough for non-experts in geospatial data and geospatial information systems to understand and use*. Complexity in geospatial standards often stems from the fact that they cover a wide range of use cases, many of which are not required by non-experts.
- *`Web-oriented:` The standard is web-developer-friendly*, i.e. meets the expectations of many Web developers, for example by using encodings that are common on the Web, using HTTP verbs, etc. Note that this is a different criteria from the previous one; for example, it's about developers preferring encodings such as JSON to XML/GML. Note: what's 'developer-friendly' can be a trend sensitive thing.

Rationale: WMS allows the use of parameterized URLs, but returns XML messages.
## Web Map Service (WMS)

(Is WMS using webarch correctly? Is it not too comples for non-experts?)
| `Scorecard` | | |
| ------------------------- |:------------:|:------------------------------------------------------------------------|
| `Criteria` | `Rating` | `Rational`|
| WWW-aligned | Yes | The fundemental concepts are adhered to. One could argue that a more RESTful approach would be a necessary step towards modernization of the standard. |
| Accessible | No | Many of the required parameters assume a priori knowledge about OGC standards and geospatial concepts such as CRS, BBOX, Layers, Version, Service, etc. |
| Web-oriented | No | WMS allows the use of parameterized URLs, but returns XML messages. No support for JSON.|

## Web Map Tile Service (WMTS)

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Map Tile Service (WMTS)| ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Web Coverage Service (WCS)

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Coverage Service (WCS)| ? | no | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Web Coverage Processing Service

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Coverage Processing Service| ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Catalogue Service (CSW)

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Catalogue Service (CSW) | no | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth. Catalogue services cannot be crawled by web indexers.

## Web Map Context

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Map Context | ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Web Processing Service

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Processing Service | ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Web Service Common

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Web Service Common | ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Sensor Observation Service

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Sensor Observation Service| ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Sensor Planning Service

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Sensor Planning Service | ? | ? | no |

Rationale: Using http only as a transport protocol, sending XML messages back and forth.

## Observations and Measurements (O&M) GML encoding

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| O&M GML encoding | n.a. | ? | no |
Expand All @@ -91,27 +102,31 @@ Rationale: The encoding is not web-developer-friendly.
Note: The concepts of the standard have for a large part been incorporated in SSN.

## Timeseries (Profile of Observations and Measurements and the XML Encoding)

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Timeseries | n.a. | no | no |

Rationale: The XML encoding is too complex and verbose - not lightweight enough to conduct, for example, enhanced (near) real-time operations involving moving objects, via the Web.

## Moving Features

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| Moving Features | n.a. | no | no |

Rationale: The XML encoding is too complex and verbose - not lightweight enough to conduct, for example, enhanced (near) real-time operations involving moving objects, via the Web.

## IndoorGML

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| IndoorGML | n.a. | no | no |

Rationale: Too complex and the GML encoding is not web-developer friendly. A JSON encoding might be created from the conceptual model, but people have indicated it may currently be too complicated for that. This standard is potentially relevant for mobile web applications, though.

## CityGML

| `Scorecard` | webarch | simple | dev-friendly |
| ------------ |:------------:|:------------:|:------------:|
| CityGML | n.a. | no | no |
Expand Down