WIP: Added report for topic #4 #1
Conversation
meerman
force-pushed
the
topic_4
branch
5 times, most recently
from
38e583a to
e9b0605
Compare
meerman
force-pushed
the
topic_4
branch
2 times, most recently
from
ba8945d to
a3178d0
Compare
| This document contains the main report for topic #4. It also contains the list of deliverables and links to the various repositories. | ||
|
|
||
| This topic is researched using the following projects: | ||
| - Goaf. Goaf is a Golang implementation of the OGC API Features API. This project can be found at https://github.com/PDOK/goaf |
There was a problem hiding this comment.
OGC API Features API , 2x API
ook goed om te benoemen dat het part 1 van de spec betreft
There was a problem hiding this comment.
OK. tekst veranderd.
| ### Summary | ||
| This topic is concerned with a comparison between a convenience API and the OGC Features API. The report takes an existing (convenience) API and investigates the costs and benefits of adding the OGC Features API to it. | ||
|
|
||
| The main conclusion of this report is that there are use cases where adding an OGC API implementation to an existing convenience API can provide great benefit. Important to realize is that the cost of adding an OGC API implementation is relatively low, if a library responsible for serving the API is already present. Without a library, the cost of implementing the OGC API specifications can be (too) high. |
There was a problem hiding this comment.
m.b.t. tot "(too) high", ten opzichte van wat? WFS2.0
There was a problem hiding this comment.
toegevoegd 'ten opzichte van eventuele winst' (usefulness)
| This research is limited by the following constraints: | ||
| - We will only approach the research question by taking an application with an existing (convenience) API and investigate the cost and benefit of adding an OGC API Features implementation. We acknowledge that the question can also be approached the other way (take an existing OGC API Features implementation and add a convenience API). We also acknowledge this approach as interesting. However, due to resource (time) limitations, we have chosen to only investigate the first approach. | ||
| - We make the comparison by looking at a system that contains location data, but also measurement data. The topic is about the OGC API Features, not about OGC measurement APIs. Therefore, we will only use the location data for this topic. | ||
| - We will demonstrate the added functionality that becomes available when data is accessible using OGC API Features with only one client application (QGis). We implicitly generalize this to the functionality of other OGC compliant client applications. |
There was a problem hiding this comment.
OK, door het hele document gewijzigd.
| ### Approach | ||
| The approach to this topic is to delve into the OGC API Features and to investigate the investment and possible return of adding an OGC API Features compliant endpoint to an existing service. | ||
|
|
||
| To do this, we will start with an existing convenience API. This is done by taking the API from an existing open system by a Dutch organisation called 'Kadaster' that contains location data. We will investigate the full potential with a datasource containing water quality an quantity measurements for the Dutch water authorities (Rijkswaterstaat en waterschappen). For the latter, we will only take a look at the location part of their API. |
There was a problem hiding this comment.
"existing open system", De NSDI/PDOK bedoel je?
"location data", welke dataset?
There was a problem hiding this comment.
Klopt, deze alinea is niet goed. Ik probeer over twee systemen te praten: Goaf en DenW. Deze formulering haalt ze door elkaar. Ik heb de alinea's uit elkaar getrokken.
| Given the complexity of the research topic, we will approach the questions using a variety of different methods. The results from these methods will be combined into a single set of conclusions. The overall method is therefore a case study. | ||
|
|
||
| ### Demonstration with QGis | ||
| The first way to demonstrate benefit is by demonstrating the datasource being accessed by an OGC client, QGis. We will not demonstrate all the capabilities of OGC clients; there are ample examples available on the Internet. |
|
|
||
| #### Code review on library | ||
|
|
||
| The design of the library as well as the implementation have been submitted to the project owners of Goaf (a team of Kadaster). They were asked to criticize the design. They find the implementation, at face value, sufficient for further exploration. They want to use this library for a different project. The have also stated that a conclusion cannot be drawn without actual using the code in a different project. |
There was a problem hiding this comment.
"They want to use this libray for a different project" <- niet geheel juist
- we zitten in de toekomst met meerdere OGC API gerelateerde projecten
- m.b.t deze library, klopt "sufficient for further exploration" dus eerst (los van code review enz..) PoC implementatie voor dat dingen richting PROD o.i.d. gaan
There was a problem hiding this comment.
OK, tekst verhelderd. Is dit ok?
| With respect to ease of expansion, there is decoupling in the following functional areas: | ||
| - The 'Features' part is independent from the main engine. This means one doesn't have to use/ load the features part, but can use instead other OGC API Features, such as the tileset. This leads to ease of expansion with respect to the OGC API standards. | ||
| - The library contains default json and html templates. However, these templates can be replaced by other json or html templates. This leads to ease of expansion with respect to the (most) common templates. | ||
| - A developer can easily add other template formats, such as Geopackage. This can be done by simple adding other templates to a service. This leads to ease of expansion with respect to output formats. |
There was a problem hiding this comment.
template formats? -> waarschijnlijk: datasources
There was a problem hiding this comment.
Het is template formats. Het gaat hierbij niet om wat je erin stopt, maar wat eruit gaat. Bijvoorbeeld data outputten als CSV off geopackage of iets anders. Duidelijker gemaakt dat het gaat om output formats.
|
|
||
| #### Subjective experience of library development | ||
| When implementing the specifications in the library, the developers had the following experience: | ||
| - Experience in working with Geodata, including implementing the OGC WFS 2.0 standard. |
There was a problem hiding this comment.
zou zeggen op z'n minst de OGC API Features
(WFS 2.0 kan mogelijk zelfs in de weg zitten m.b.t. het "bedenken" van solutions)
There was a problem hiding this comment.
Ik snap je opmerking niet goed. Ik probeer hier de uitgangspositie aan het begin van het topic te benoemen; toen hadden we geen kennis van OGC API Features (wel van WFS20). Kan je uitleggen hoe ik dit anders kan doen/ hoe dit bij jou overkomt?
This commit is still work in progress. Please do not merge.