Skip to content
This repository has been archived by the owner on Oct 5, 2021. It is now read-only.

Latest commit

 

History

History
47 lines (34 loc) · 3.86 KB

lessonsAndNextSteps.adoc

File metadata and controls

47 lines (34 loc) · 3.86 KB
Raw

Immediate Lessons and Next Steps

Immediate Lessons

  • The Tiles API is reasonably stable. We have seen different interpretations of how to apply styles to collections maps and the dataset maps.

  • Evolution of WKSS into common TMS (the ones that are going to be registered). The evolution has taken us to a conclusion that WKSS.

  • The concept of buildings blocks has been completely demonstrated. The three APIs have been successfully demonstrated together.

  • The sprint has shown that a lot that is common can be shared across the APIs i.e. how much OGC API - Common - Part 2 facilitates the client implementation.

  • The interaction between Maps, Tiles, Styles worked well. No major issues came up that could not be verified.

  • More work needs to be done on Styles in general. e.g. where we use the styles has an impact on the resources.

  • We focused on the API aspects of the styles but not on the formats of the styles. More work is needed on the formats aspects of the styles (e.g. SymCore).

  • While in the Tiles API we have developed a metadata model, in the Maps API there has been less interest in developing a specific metadata model.

  • TBA

  • TBA

Implications for the needs of NMAs

What will the APIs do to help meet the following needs?

  • Providing the public with access to geospatial data and maps: The OGC APIs will make it easier for the general public to access maps through regular web browser technologies. For example, throough OGC API - Maps it is now possible to access a complete map through a basic URL (i.e. no query parameters). OGC API - Tiles will make it easier to publish maps as vector tiles, which are becoming increasinly popular in the NMA community. The APIs are able to provide data in a way that 2.5D and 3D visualisation clients are able to handle.

  • Facilitating analytics: OGC API - Tiles one is able to publish tiled coverage data in such a way that makes it easier to 'stream' coverages for analysis at the screen resolution. This makes it possible to create histograms, vegetation indices, and other analytical reports all at the screen resolution. The flexibility of specifying the origin of the tiles will make it easier to combine regular OGC tiles with other tiles.

  • Reducing barriers to accessing geospatial data: All of the OGC APIs together make it easier to start with a dataset and then find a way to generate tiles and other resources. The OGC APIs are integrated in a very convenient way. The Styles API makes it possible for NMA’s to publish styles from a central location in a way that is consistent with how they publish data. The integrated environment makes it easier to manage things together.

Next steps

How will the sprint’s outcomes will be incorporated into future OGC Standards Program and Innovation Program activities?

Next Steps for the Innovation Program

There is a need to:

  • experiment with multidimensional support in OGC APIs.

  • explore how we turn legends into real data(objects) that can be combined by the client (e.g. asking a client to provide the elements that are in a legend).

  • research how simple a structure needs to be to meet the needs for a legend while also being easily implementable.

  • experiment with coverage tiles, as they are becoming increasingly important (e.g. in support of rendering DSM’s and DDIL environments). Strategies for identifying suitable sizes of the tiles needs to tested/researched.

  • experiment with non-grid coverages (e.g. point clouds).

  • explore the possibility of an info capability that supports different data sources. *

Next Steps on the Standards Program

There is a need to:

  • implement a legend capability for the Maps and Tiles APIs.

  • implement an info capability for the Maps and Tiles APIs.

  • implement an OGC API - Maps conformance class/extension to support time dependent maps (in a way similar to the WMS Best Practice for Time Dependent) e.g. the subset and datetime parameters

  • TBA