OGC API feature services built with Hakunapi
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 | 266 | |
| Author | ||
| License | CC Attribution 3.0 Germany: 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/66494 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS4G Prizren Kosovo 2023108 / 266
10
17
23
44
45
46
47
48
49
50
52
53
80
84
85
91
110
116
129
148
164
167
169
173
174
181
182
183
186
187
199
202
204
206
209
215
241
248
265
00:00
Open sourceTrailProduct (business)Server (computing)Service (economics)Web serviceInternationalization and localizationArchaeological field surveyBuildingComputer animation
00:18
Internationalization and localizationServer (computing)Content (media)Java appletOpen sourceWeb servicePersonal digital assistantService (economics)Source codeServer (computing)CASE <Informatik>MultiplicationProxy serverSelf-organizationComputer animation
00:48
Internationalization and localizationOpen setSelf-organizationDatabaseRaster graphicsLecture/Conference
01:08
Boundary value problemCategory of beingDatabaseRaster graphicsEndliche ModelltheorieSpeicheradresseInternationalization and localizationDigital photographyMappingAreaMorley's categoricity theoremComputer animation
01:27
Generic programmingOpen setMobile appMobile WebDesign by contractClient (computing)Type theoryLatent heatService (economics)Open setClient (computing)Generic programmingServer (computing)Morley's categoricity theoremINTEGRALCustomer relationship managementSheaf (mathematics)FreewareStack (abstract data type)Different (Kate Ryan album)Address spaceDesign by contractKey (cryptography)Data Encryption StandardMusical ensembleWeb 2.0Internet service providerType theoryMobile appSoftwareComputer animation
03:58
Internationalization and localizationPersonal digital assistantWeb serviceProcess (computing)Vector spaceSynchronizationQuery languageMobile WebProxy serverMobile appClient (computing)File formatData structureServer (computing)ImplementationService (economics)Shape (magazine)Similarity (geometry)Raster graphicsAerodynamicsFluid staticsSeries (mathematics)BuildingRevision controlOcean currentWeb 2.0Level (video gaming)Server (computing)Process (computing)Web serviceVaporPoint cloudComputer animation
04:40
StatuteWeb serviceInternationalization and localizationConsistencyRevision controlFile formatComplex (psychology)Web browserClient (computing)MereologyCore dumpSystem programmingCoordinate systemElectric currentDigital filterDynamic random-access memoryBuildingOracleService (economics)Query languageCartesian coordinate systemMoving averageServer (computing)Web serviceAddress spaceData typeComponent-based software engineeringComputer animation
06:13
Service (economics)Computer configurationCore dumpStreaming mediaScale (map)Table (information)DatabaseLatent heatWeb serviceTransformation (genetics)Type theoryCodeLogical constantCategory of beingOpen sourceArchitectureInternationalization and localizationMethodenbankBeta functionSource codeJava appletServer (computing)File formatFunction (mathematics)Physical systemWeb browserConfiguration spaceHardware description languageComputer architectureFunction (mathematics)Data storage deviceComponent-based software engineeringSoftware developerCartesian coordinate systemCategory of beingServer (computing)Multiplication signWeb 2.0CodeScaling (geometry)File formatWeb pageComputer animation
08:52
Data modelSampling (statistics)Musical ensembleWeb serviceSet (mathematics)View (database)ImplementationWorkstation <Musikinstrument>Address spaceFunction (mathematics)Web 2.0Demo (music)Repository (publishing)Open setRule of inferenceCartesian coordinate systemLecture/Conference
10:42
Formal languageData modelOpen setComplex (psychology)MereologyCore dumpSystem programmingCodeJava appletLatent heatCustomer relationship managementCASE <Informatik>Local GroupPoint (geometry)Instance (computer science)Numbering schemeAxonometric projectionFunction (mathematics)Data typeData modelDatabaseConfiguration spaceRight angleComplex (psychology)Social classFunction (mathematics)CodeWeb serviceJava appletQuery languageLevel (video gaming)Connectivity (graph theory)Type theoryProjective planeComputer animation
12:19
Web serviceGateway (telecommunications)Meta elementDatabaseComplex (psychology)Java appletCodeMetadataCore dumpEnterprise architectureQuery languagePersonal digital assistantServer (computing)Level (video gaming)Web serviceCartesian coordinate systemComputer architectureProjective planeVisualization (computer graphics)Greatest elementDatabaseJava appletConnectivity (graph theory)CodeCASE <Informatik>Configuration spaceMusical ensembleRaster graphicsType theoryCache (computing)
14:46
System programmingCoordinate systemClient (computing)Complex (psychology)BuildingService (economics)InformationMereologySocial classDigital filterCurvatureServer (computing)Computer configurationCodeJava appletServer (computing)Order (biology)Complex (psychology)Mechanism designClient (computing)Physical systemBitSoftware developerMetadataInformationCoordinate systemWeb serviceMereologyFeedbackCartesian coordinate systemDirection (geometry)Exterior algebraType theoryComputer animation
17:22
Service (economics)Core dumpExtension (kinesiology)Java appletCodeEnterprise architectureGeneric programmingLatent heatMethodenbankRevision controlSoftware frameworkLocal ringThread (computing)Vector spacePersonal digital assistantGateway (telecommunications)Meta elementClient (computing)MereologyDigital filterComplex (psychology)Server (computing)Complex (psychology)CodeConfiguration spaceJava appletExtension (kinesiology)Cartesian coordinate systemCASE <Informatik>Software frameworkMultiplication signSocial classClient (computing)Repository (publishing)Software testingCone penetration testPlanningComputer architectureDifferent (Kate Ryan album)ImplementationMereologyEnterprise architectureCore dumpConnectivity (graph theory)Centralizer and normalizerMethodenbankLatent heatConformal mapComputer animation
21:05
Software developerCore dumpBuildingService (economics)Computer animation
Transcript: English(auto-generated)
00:08
Thanks. So, yeah. I'm from the National Land Survey of Finland, and talking about our solution for building
00:24
OTC-ABI feature services, and also covering some of our use cases and how we are transitioning
00:41
from BFS services to OTC-ABI. First, our organization maintains multiple registers for housing shares and other registers
01:07
too. Also, we have a lot of open data and traditional GIS data from topographic database and raster maps, aerial photos, and so on, but I move to APIs then.
01:26
First, I have some categorization of APIs we provide. There's categorization about API access types or how they are offered to different customer
01:51
segments. First, they are open data APIs with free and API key access. Then they are contract-based APIs for open and licensed data, and also private APIs.
02:10
All these are provided with same software stack, but for different channels.
02:22
Then other side, API client technology. It also affects how our APIs are, how interoperably they really are. For example, web and mobile apps for generic user clients, they can easily consume REST
02:47
or open API type of APIs, but they have to manage care space I think somehow. Then if there's web and mobile apps that are care space are based, they depend on
03:04
some JavaScript or other library that it has to have compatibility for some standard. And GIS desktop clients are slowly adapting new OTC standards.
03:25
And the last section here is we have also many kinds of data access or integration providers that can go to the clients with just coding connectors, but if they are relying
03:49
to care space servers, those tools should also adopt those standards first.
04:01
Our current standard stack is presented here. There are vapor map services and cloud services, coverages, also some processes, but I'm not talking about them. I'm focusing now to feature services, and now we are moving from the traditional web
04:28
feature service standards to OTC API features, and how we got there, about five years
04:47
ago we were building VF, WFS APIs with GML data types.
05:02
There were some difficulties to build these services, applications were quite complex, then there are different tools to handle, and it was difficult to implement very fast
05:25
and efficient services. And even if these traditional OTC standards are well known in GIS space, they are not
05:40
so easy outside GIS space. So we were quite excited when WFS3 was announced about five years ago, and that then matured to OTC API feature standard.
06:12
And our solution for OTC API is our own software component that is called Hakunabi.
06:28
We started it when the new standards came available as a draft standard, we started development already then, there were not so many solutions available at that time,
06:50
so we ended up to build our own solution that was built to support our geospatial
07:08
data and API architecture, but also there were some key principles on developing and designing these solutions.
07:22
We had to have simple feature applications provided easily with configuration, but then we have also those quite difficult and complex applications, so they need more custom code,
07:51
but this solution tried to make it possible too. And also efficient data streaming was one of the key principles.
08:05
Streaming features fast and support paging and easily to scale servers. So there are some properties of this feature server called Hakunabi.
08:25
For Datastore there is only PostGIS, Datastore fully supported, and for output, the main
08:51
package and some other formats has been also tested, but not fully supported.
09:05
Then there is some samples. This sample is provided on the GitHub repository of this Hakunabi package.
09:23
It's just addresses from open data, dataset that is freely available, and this demo service follows geospatial encoding rules for InSPIRE addresses.
09:44
But here's HTML view and then geospatial output. But then, as I already said, all applications are not simple.
10:02
Here's some data. This data model is in Finnish, so I don't go in details, but still we can implement OTT API features service providing geospatial output.
10:25
And another sample of geographic names here. It's quite simple dataset, but there are simple feature data models and also some
10:49
more complex features or feature types. And for this service, there's on the right side describe on the bottom what steps is
11:11
needed to implement service based on this component. So you have some code for configuration, entity classes, handle some queries, collection
11:29
classes, database queries, and some modifications to output for others too. So some code was needed on this service outside, not such configuration.
11:56
There is geostation and TML output from place names.
12:05
Other is in VGS84 coordinate, and on the right it is some Finnish map projection.
12:22
Then a simplified architecture layout of our services for OTT API features.
12:40
And on this picture, there are also other tools, there are tier server is used for map visualizations on server, map server is used for raster data, and map cache for tiling, but I'm not talking about them, so I'm now concentrating to feature services
13:06
only. There are different databases on the bottom, and then there is some service layer based on this.
13:21
There are both simple feature services that are implemented just by configuring configuration from database schema to feature schema.
13:43
So those services do not need any Java code, but then there are those more difficult application schemas that, as I already said, need also custom Java code. So those were the use cases that are with port text.
14:09
Then there are some other use cases that we have been using this component, but they
14:20
are more specific to our infrastructure, so they are not so generic, but those bullet use cases can be implemented using the component we have been open sourced.
14:44
Okay, so then some challenges when building feature services based on new RTT API standards.
15:03
First, client support is still growing slowly. They are clients that support these services, but then they are clients and some clients are giving us feedback that why we are moving to RTT API, but that's the direction we
15:29
are moving. Then standard development, there are new ways the standard is implemented and can be followed
15:43
on GitHub, but maybe it's still a bit moving target after five years of standardization, but it certainly gets completed.
16:02
Those complex application schemas, they are difficult in older feature services, but they are difficult also on new RTT API services. Also, alternative coordinate system other than VTS84 needs some care of how to implement
16:34
and how to provide them and how to be sure that clients can use those other coordinate
16:46
systems we provide on our services, as they are also. The standard part two has some mechanism to announce also information or metadata
17:06
about what is the coordinate system and what is the access order on those coordinates. So it is possible to publish this alternative coordinate system too.
17:24
Then some pros and cons about this solution. So complex features are supported, but at the same time it needs a lot of custom Java code to implement them.
17:42
Simple feature application schemas are more easily implemented with off-the-shelf component solution just by configuration. This is validated with OTC test suite.
18:06
The component is a framework. It can be extended to different use cases. Java code is quite good with quite good modularity and it should be quite efficient.
18:26
But then other cons. This solution is currently focusing only on features and if implementing extensions
18:41
based on this solution, the solutions are often enterprise architecture specific. No package is yet published on Maven Central, which is planned. This solution is currently used only by us.
19:08
So conclusions. OTC APR features based on geostation is applicable for simple schemas
19:23
and with some coverage only for complex application schemas. Secondly, TIS client support for these new standards is still evolving.
19:42
And our solution is Hakunabi, which is Java-based for OTC APR features and with post-gis support. Code is available in GitHub and some planet issues for next steps.
20:10
This GitHub repository needs some more documentation. And secondly, we look for new JSON-FK standard.
20:27
Maybe hope to support at least core conformance class of it. And the OTC API features part 3, which is still draft standard,
20:46
may also need some implementation on this Hakunabi solution when the standard is approved. Yeah. Thank you.