It's all about reusability.
Each OGC API standard is made of a set of requirements, or building blocks, which can be reused beyond their original context.
- A building block could be a complete OGC API standard (e.g.: OGC API Features), one part of a multi-part standard (e.g.: part 1 - Core) or more granular functionality whithin the standard, such as data types or parameters (e.g.: bbox, crs).
- One or more building blocks can be integrated into existing/novel web applications.
- Each building block represents a testable interface component.
Whether you need a complete web API to access a geospatial resource or just some bits to geo-enable your web application, the OGC building blocks could be a solution to provide standard, testable, interfaces, some of which with a high level of maturity.
Let's not reinvent the wheel!
Granular Resources
Did you ever have the need to define a bounding box parameter in your application? It is easy: you can just create an array of coordinates. But should you use the coordinates of the lower left and upper right corner, or upper left and lower right corner? What about the order - should it be x,y or lat,long ? And what happens with the crs?
// Here are a couple of variations for a bbox representation.
// Lower left, Upper Right - x,y
const bbox1=-[124.7844079,24.7433195,-66.9513812,49.3457868];
// Upper left, Lower Right - x,y
const bbox2=-[124.7844079,49.3457868,-66.9513812,24.7433195];
// Lower left, Upper Right - y,x
const bbox3=-[24.7433195,124.7844079,49.3457868,-66.9513812];
Every day, developers around the world solve this same problem, in a slightly different way. And yet this is exactly what we want to avoid with the location building blocks - people solving the same problems, again and again - even if they solve them well, which is not always the case. The granular building blocks are used by the OGC APIs to address the requirements of these APIs, which are common requirements of location APIs; for instance: the need of a bounding box parameter or an extent data type. Next time you need to address a geo requirement in your application, instead of spending time thinking about a solution, check-out the existing location building blocks.
Developer Documentation
Developer documents cover different aspects of designing, building and testing a BuildingBlock for reuse within your own application or publication to one or more Building Block registers.
Documentation can be found here. (This is a work in progress)
OGC APIs
Each OGC API is a bundle of modules, combined to provide a convenience API for access to a specific resource type (e.g.: feature, coverage, tile).
For instance, OGC API - Features provides a web interface to access feature resources, using different parts:
- Part 1: Core - allows for the provision of feature data in WGS84 CRS to any compliant client. The client can retrieve or display the feature data.
- Part 2: CRS by reference - extends the Core with the ability to use CRS, other than the default one.
Each module provides testable conformance classes, which can be used for procurement. OGC conformant modules can be combined with other modules to add OGC capabilities to a Web API implementation.
Try the OGC API ConfiguratorFrequently Asked Questions
These are some frequently asked questions about OGC location blocks. If you think your question was not answered here, please drop as an email at .
-
How do I know if the
OGC building blocks are for me?
Whether you want to implement an API to access some kind of geospatial resource, or you want to spatially enable your API, you should check out the OGC building blocks. Even if you just need a small piece of functionality, the odds are this already exists. Adopting OGC building blocks also has the benefit of bringing interoperability into your application. On the other hand, if your application does not deal with geospatial data in any way, you probably do not need the OGC building blocks.
-
Why
should I use non geo OGC building blocks in my application?
You actually do not need to use those. They were created to ensure consistency within OGC API's where there was not a clear mainstream standard. They aim to be in line with best practices of the web and could be replaced, e.g. by building blocks specified in an IETF RFC or similar, if and when they are available. Although API's built with the geo building blocks do not need to use these, they provide a nice default option that OGC-focused tools will understand.
-
Do
I need prior knowledge of OGC standards or GIS, in order to use the building blocks?
You do not need any prior knowledge of OGC standards, in order to use the building blocks. They are completely standalone. If you are using geospatial data, depending on your use case you probably need to understand some concepts, like coordinate reference systems or bounding boxes, but that is about it.
-
Which
technologies are used in the OGC - Location building blocks?
The building blocks rely on the technologies and best practices used in the web, in general: use of standard http methods, use of http status codes, content negotiation, recommended YAML and JSON encodings, OpenAPI definition.
-
How
do I know which OGC APIs/ parts of OGC APIs I need for my application?
You can start by trying out the OGC API configurator.
-
Do
I need to read through the standards documents, in order to implement the OGC APIs building
blocks?
The OGC APIs are documented using OpenAPI. In most cases, you can explore that documentation on SwaggerHub.
-
Who
develops the building blocks?
The OGC APIs are developed by their corresponding Standards Working Groups (SWG). When a SWG identifies something which has the potential to be used outside the original context of the OGC API, they incubate it as a granular building block.
-
So
far, there are only a few building blocks. Can I expect more?
As they evolve, it is expected that more OGC API will produce building blocks.
-
How
can I know the level of stability of a building block?
Parts of OGC APIs which are published as approved standards, are expected to be stable. The most granular building blocks are published with an associated maturity level, which gives an idea of their stability.
-
Can
I test the conformance of a building block?
Although tests may not be available yet, the expectation is that this will be possible.
Who is behind the location building blocks?
The building blocks are developed through a member-driven consensus process, which creates royalty free, publicly available, open geospatial standards. The Open Geospatial Consortium (OGC) is the organization which drives this process. It is supported by an active community of members, with involvement from a large range of organizations, as well as smaller ones. Join OGC today!