OGC API Standards: Past, Present, and Towards an Exciting Future
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 351 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/69034 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2022 |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FOSS4G Firenze 2022210 / 351
1
7
13
22
25
31
33
36
39
41
43
44
46
52
53
55
58
59
60
76
80
93
98
104
108
127
128
133
135
141
142
143
150
151
168
173
176
178
190
196
200
201
202
204
211
219
225
226
236
242
251
258
263
270
284
285
292
00:00
Presentation of a groupBitComputer animation
00:20
Langevin-GleichungComputer fileInformationOpen sourceTime domainDigital photographyOpen setSelf-organizationWeb serviceProcess (computing)BitInformationSelf-organizationServer (computing)Universe (mathematics)Web 2.0Proxy serverLaptopDomain nameMixed realitySoftwareTerm (mathematics)Client (computing)Video gameProcess (computing)Physical system2 (number)Computer animation
02:55
Digital photographyContext awarenessElement (mathematics)Rule of inferenceGroup actionProcess (computing)ResultantCASE <Informatik>Computer animation
03:30
Element (mathematics)Social classLibrary catalogComputer-assisted translationWeb serviceConsistencyOpen setSoftware developerGreen's functionSystem programmingDiscrete groupPressureInformation retrievalIntegrated development environmentSoftware developerMereologySocial classLatent heatImplementationGroup actionWeb 2.0FamilyCASE <Informatik>Web serviceCodeMathematicsMultiplication signChannel capacitySearch engine (computing)Repository (publishing)Open sourceDescriptive statisticsInteractive televisionConformal mapSoftware testingCore dumpGame theoryWeb pageType theoryUser interfaceRoutingProcess (computing)1 (number)Level (video gaming)Instance (computer science)MappingDifferent (Kate Ryan album)EntropiecodierungContent (media)Web-DesignerSlide ruleOpen setComputer animationEngineering drawing
08:24
Musical ensembleGoodness of fitWeb serviceComputer animation
08:44
Server (computing)Client (computing)Open sourceDisintegrationSoftware frameworkSystem programmingCodeText editorProduct (business)ImplementationGroup actionComputing platformVisualization (computer graphics)Web serviceDigital librarySpatial data infrastructureMultiplicationSeries (mathematics)InformationImplementationSuite (music)Moment (mathematics)Semiconductor memoryClient (computing)Projective planeServer (computing)Real numberINTEGRALCASE <Informatik>CuboidOpen sourceSoftware frameworkPresentation of a groupSoftwareCore dumpWebsiteElectronic mailing listConnectivity (graph theory)Right angleSoftware testingSlide ruleFamilyProduct (business)Computer animation
11:59
PressureOpen setEvent horizonCodeStreaming mediaOpen sourceFile formatMereologyMultiplication signBuildingSoftware developerGroup actionBlock (periodic table)FeedbackIntegrated development environmentText editorInformation retrievalPerspective (visual)EntropiecodierungProcess (computing)QuicksortTesselationRevision controlImplementation1 (number)Repository (publishing)Computer configurationTrailMoment (mathematics)MathematicsVirtualizationComputer animation
15:42
CodeFocus (optics)Texture mappingMetadataSoftware developerHybrid computerEvent horizonMetadataMappingFocus (optics)Row (database)MIDIEntropiecodierungWeb 2.0File formatTesselationInheritance (object-oriented programming)Set (mathematics)SubsetComputer animation
16:52
Slide ruleMereologyComputer animation
17:14
Product (business)Time domainGroup actionSet (mathematics)Internet forum
Transcript: English(auto-generated)
00:00
Okay, thank you. Good afternoon. Thank you for being here in the last talk of the last session. So this presentation is going to be about OGC API standards and is by myself and Etina Trakas, which is in the back of the room.
00:20
So I'll start with a bit talking a little bit about why I think it's important to use standards and how we can use them. So basically, standards are important to share geospatial information in an efficient way.
00:41
So to make sure that the systems integrate well with each other and that data is reusable, which is ultimately what we want to achieve. We don't want data to remain in silos, but we want it to be reusable. According to these fair data principles, which say that information should be findable, accessible, interoperable, and reusable.
01:06
So this would be like the ideal world. So we have, I want to connect to a server, and it doesn't matter what the software is. It could be PyGEO API, it could be LDProxy, something else. And then I want to use a client to connect to this server.
01:29
And the client could also be a Jupyter notebook, or it could be QGIS. So actually, as a user, I should not care about these things. I should not be forced to use a specific client or to connect to a specific server.
01:45
Because all of them are using a standard. So this is the final goal of interoperability. So in the example here, the standard that I'm using is OGC API features, which I'll talk about in a second.
02:03
So in terms of standards, there are many organizations that deal with standards. We have the W3C, the web consortium, which deals with standards for the web. But in the scope of our domain of geospatial information, OGC is the organization who is actually taking care of these standards.
02:26
And it's a member organization, so who is developing the standards are actually the members. And they do this through a collaborative process. So we have different members from all corners of life. So there are organizations, like you see, these are just an example.
02:46
But there are organizations, there are agencies, governmental agencies, universities, and so on. Large companies, small companies. So what is actually an OGC standard? It's just a document.
03:03
But to arrive to this document, there was a long process where the members of the working groups, they collaborate and they engage through this process, the RFC process. And they make sure that the final result is addressing all the use cases that it should address.
03:25
So it's achieving the optimal interoperability. So what's inside the standard? If you look at the document of standard, you'll see that there are requirement classes. So these are the requirements which are basically just specifications that the standard needs to address.
03:52
And these requirements are very important that they are testable. Because we need to be able to say this particular implementation is conformant to the standard.
04:05
So each group of requirements, there are groups in classes, and then these classes are grouped in conformance classes which are going to be tested. This is an example of how a requirement looks like and how a test looks like.
04:23
So the test should be abstract. It's completely agnostic about the implementation. So I think many people have heard about OGC standards. Maybe you recognize some of the standards in this slide.
04:44
Like is the case of WMS or WFS and so on. So they've been around for a very long time, and they are at the core of many spatial data infrastructures. But they were designed actually a long time ago, a time that we still had Spice Girls and Game Boy.
05:06
And at that time, the web was also very different from what it is today. So there were many different changes. At that time, SOAP was a technology that was very ubiquitous.
05:20
And the encodings with XML were really popular. But things have changed, fortunately, some may think. And things have also changed within OGC. So OGC wanted to actually embrace these changes and leverage all the capacities that we see in the modern web.
05:42
So using HTTP status methods, status codes, content negotiation, and so on. Also to improve the discoverability of geospatial data. So a lot of people are searching for data in the search engines these days.
06:01
So it's important to leverage schema.org. And moreover, it's an open development. So the development of the standard is made in the public eye in GitHub repositories. And anybody can actually follow and even contribute to it.
06:23
There's also the adoption of the OpenAPI specification. So you can actually, as part of the standard, you have a description of how the standard works in an interactive manner. So if you use the OpenAPI or even Swagger, you're familiar with this interactive web interface
06:44
where you can go and test the requirements and look at the response and understand how the standard works. In an interactive fashion. So without actually having to read all the documentation or all the pages that compose the standard.
07:09
So this is ultimately what OGC wanted to achieve. It's just like improving the developer experience. And making sure that people that are not familiar with OGC standards or even with GIS,
07:25
so mainstream web developers, are able to quickly look at these standards, look at the OpenAPI specification, for instance, and start studying it and developing something very quickly. So the OGC API family includes many different standards, as it was the case for the OWS services.
07:53
So depending on the type of data that you want to expose, you could use OGC API maps,
08:01
or you could use OGC API routes or coverages or processes. So depending on the type of geospatial data, you would choose a different standard. And they are in different stages of development. So the ones that you see in green, they have at least one part that has been already approved.
08:26
So this is the key question. Who is using these standards? Because a lot of people are using the OWS services. Is anyone actually using these new OGC APIs? Okay, I see someone in the back. Anyone else? All right.
08:42
Okay, that's good. So we have many people in the room which are using these standards. So at this moment, if we look at the OGC API features, which within this family is the, we can say is the most mature one, you will find there are Tevin server-side implementations of the standards.
09:05
So maybe eight client-sides. So maybe some of the software that you are already using is implementing this standard, either the client-side or the server-side. And this list is growing every day.
09:20
So just recently there was an integration, a component that was added to Apache Camel, which is an open source framework from Apache, which allows users to integrate a data source which is published using OGC API features.
09:41
And it's in pre-release right now, but it will be released soon. So what about OSU? OGC API is an OSU. There are actually many OSU products that implement OGC standards.
10:03
This is not only for OGC API, this is for all the OGC standards. But if you look at them, they are compliant, so they are listed. This means that they are listed in the OGC website as compliant because they went through the tests that make sure that the standard is certified.
10:25
And all of them are also reference implementations. So reference implementations are extremely important because they are publicly visible and people can inspect these implementations and understand how the standards work. So all these projects are both compliant to the standard and reference implementations.
10:46
And some of them are even also early implementers. So if you were in the talk, in the keynote this morning, you'll see that there is a new MOU memory of understanding between OSU and OGC.
11:04
And through this MOU, we hope to see more projects joining this OSU Hall of Fame. There are also real use cases of deployments of OGC APIs. I just mentioned three here, there are many more.
11:22
And two of them, WIS in a box and emotional cities were actually presentations that were shown here in this FOS 4G. So these are use cases that were presented here during this conference.
11:41
And all of them, the three of them, are using at their core PyGU API, which is a Python implementation of a suite of OGC API standards. So it means implementing actually several of the standards that I showed in the previous slide.
12:03
So what is the status of all these OGC APIs? They are all in development, so this is the thing. They started around 2017 and they are all in development. But the OGC APIs are developed in parts, so we can say in building blocks.
12:24
So one part is approved and then we move to another part is approved. So you can use already some of these APIs. I mean you can use actually all of them, but the ones that are in green are the ones that have been already approved.
12:45
So at this moment, as it stands, you have OGC API EDR, environment data retrieval, OGC API command, which is transversal to all the APIs,
13:01
OGC API processes, and OGC API features. And very soon, OGC API tiles will also be an approved standard. So this calendar is sort of forecast because we don't know exactly the dates that they will be released.
13:21
But as it stands, we are going to see at the end of this year and during next year, we are going to see more parts of OGC APIs being approved. So as I said before, the development is taking place mostly,
13:41
or a great part of the development is taking place on the GitHub repositories. This means that anyone can look and watch, monitor the status of the standards and even contribute. So if it's something that you feel is not being completely addressed in the standard,
14:01
you have the option to file an issue or even why not create a pull request. If you are confident, this could be a good change. And the code sprints. The code sprints are also part of the development process of the standards.
14:22
So basically, around four or five times a year, a group of standards is selected and they are put into this code sprint. And this is like putting them in front of the developers and people are implementing the standards and providing feedback to the editors.
14:42
So it's a very collaborative process between the people who make the standards and the people who use the standards, which sometimes can be the same, but hopefully not because then we can have different perspectives. And normally the outcome of these code sprints is very positive
15:01
because the standard can move forward and also the implementations get updated to the latest version of the standard. So as you can see, the standards are in development, so if you want to keep track of what is happening, it's really important to be present in the code sprints.
15:22
And they are in hybrid format, sometimes virtual. It used to be virtual during the pandemic and now we're trying to move them to be hybrid, so you are very welcome to attend in person, but you can also join virtually.
15:44
So there is an upcoming code sprint in mid-September. This one is going to be in London and it's going to specifically focus on metadata. So it's a joint code sprint organized by OGC and ISO TC211
16:02
and the focus will be OGC API records, ISO 19115, STACK, and FGJSON, which is an encoding format, which is used in the standard but also in other standards.
16:22
So it's a format that is being developed more or less recently in OGC and is meant to be like a superset of GeoJSON, which is backwards compatible. There will be another code sprint towards the end of the year,
16:40
so in December, and this one will be more focused on web mapping. So OGC API tiles, OGC API maps, and OGC API styles. So I want to leave you with this last slide. I think there's no more neutrality anymore,
17:01
so either to be part of solution or part of the problem. So if we want to fix interoperability and make sure that this kind of thing doesn't happen, I think we need to be all involved. So thank you very much for your attention, and I can take some questions.