Hi all,
I'm writing to discuss a couple of issues in moving forward with the OGC
services.
Uber services?
--------------------
The new OGC APIs have such a structure that allows to either implement
services separate, or mix and match.
The common structure of resources for data services is likely:
/ (landing page)
/api (an OpenAPI document describing the API implemented)
/conformance (list of service elements implemented, aka profiles)
/collections (list of collections)
/collections/{collectionId} (the single collection description, it's sort
of a layer, but not quite one, depending on the actual service implemented)
Each service then adds extra path elements to the collection one, like for
example:
/collections/{collectionId}/items (feature service)
/collections/{collectionId}/map (map service painting one layer)
/collections/{collectionId}/tiles (tiles for a single layer)
/collections/{collectionId}/coverages (coverage service, for coverages that
are part of say a mosaic, instead of stand alone)
A service also adds some top level endpoints, like:
/map (for multi-layer maps)
/tiles (for multi-layer tiles)
/processes (cause they are not data)
/coverages (for stand along coverages not in a collection, to be confirmed)
Now, this structure allows one to expose services in two different ways,
one is separate services, the classic way, giving
each one unique element path in the URL and each one having their own
stand-alone API talking only about itself e.g.
Features:
/ogc/features
/ogc/features/api
/ogc/features/conformance/
/ogc/features/collections/{collectionId}/items
Maps:
/ogc/maps/
/ogc/maps/api
/ogc/maps/conformance/
/ogc/maps/collections/{collectionId}/map
/ogc/maps/map
Tiles:
/ogc/tiles/
/ogc/tiles/api
/ogc/tiles/conformance/
/ogc/tiles/collections/{collectionId}/tiles
/ogc/tiles/tiles
And so on... each service could be usefully interlinked with the others,
e.g., one could add a link to a collection JSON description
in features linking to the map service for portrayal of the same collection.
However it's also possible to think about a uber services, ruling them all,
with everything under the same root, e.g.:
/ogc/
/ogc/api
/ogc/conformance
/ogc/collections
/ogc/collections/{collectionId}
/ogc/collections/{collectionId}/items
/ogc/collections/{collectionId}/map
/ogc/collections/{collectionId}/tiles
/ogc/collections/{collectionId}/coverages
/ogc/map
/ogc/tiles
/ogc/processes
/ogc/coverages
This complicates matters a bit in terms of implementation, as the
archictecture would likely have to go with
a root service doing the basics and each pluggable service contributing to
each resource, e.g.:
- For the landing page, each service would have to add links to their
top level resources, making it particularly interesting to handle
freemarker HTML generation (each service would have to contribute snippets,
both here, and in all the shared resources)
- For the conformance, each would have to list its own conformance
classes
- For the API, each would have to add their own unique API paths (the
API is represented as a java bean, that each would have to add to)
For the final twist, making this configurable (e..g, allow both styles)
does not seem to be super-easy, as in Spring MVC we declare the position of
the
controller paths in the code itself... we could play with property
contributors, but it would imply a restart of GeoServer to switch service
paths, I would
also not know how to handle a mix of path styles in different workspace
(which would be a good to have for hosted geoserver deployments)
Now, to be frank, for practical reasons I'm leaning towards the separate
service approach, reasons:
- Developing them separate is easier, rather than having to open N
extension points to contribute to the uber service
- The OGC API commons is still pretty much in the air and the first
feedback about it was raised only in the hackaton (see
https://github.com/opengeospatial/oapi_common ), so the common structure
that the uber service would have to use as a base is still not stable
- Familiarity for both existing devs and users
I have however to recognize that form the point of view of a client
developer, getting everything in one place, one uber services, looks simple
and better organized (mind, one will have to rely on links to find out if a
certain resource is available for a given collection, or parse the OpenAPI
document, e.g., .../${collectionId}/items would be available only for
vectors). So I would like to hear if anyone is hellbent on having the uber
service instead, and at the same time, is happy to help with the extra work
involved in developing it, in the next few months (say from here to end of
September tops)
Tiles API, where?
-----------------------
The other issue is where to put the tiles API. If we push it back to GWC,
like a separate module,
we'd have to give up the OGC API Dispatcher support, and very likely,
develop it using plain
HTTP servlet/request/response methods.
Why is that? Because we already had to switch back from Spring MVC to that
for the restful WMTS,
since the integration with GeoServer was broken, workpace specific services
not working for example,
and generally speaking, bad interplay between the REST module, which is
sort of registering its own
"uber" configuration and MVC mappings.
On the bright side, the tile protocol is really simple, do doing that would
require not much much than
a simple recoding of the existing WMTS, which is after all pretty simple:
https://github.com/GeoWebCache/geowebcache/blob/master/geowebcache/wmts/src/main/java/org/geowebcache/service/wmts/WMTSService.java#L79
One thing to consider is that if the tiles service is developed in GWC, it
will pretty much have to be a
"stand alone" service, without knowlege about features, coverages and the
like.
If instead it gets developed inside GeoServer, it can be developed using
both standalone and uber styles, but
of course, GWC would not get one.
Finally, one can think of having it developed on both sides, on the GWC
side, to be used only in stand alone
GWC deployment, and on the GeoServer side, to be used only in integrated
scenarios. It's more work,
if we go that way I'll likely won't have time to develop it on the GWC side.
That said, porting it back to GWC should be pretty easy, one would have to
rewrite just the controller.
That's all folks
------------------
This is all. Please remember that when it comes to OGC API effort,
everything is still pretty much yet to be defined
(besides maybe the features API core), each core service is really bare
bone and often yet to solidify,
extensions are not yet written, so whatever we do now will be a prototype,
uself to give feedback to OGC
on on side, and hopefully have some head start once the API actually reach
release.
Cheers
Andrea
--
Regards, Andrea Aime == GeoServer Professional Services from the experts!
Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime
@geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
------------------------------------------------------- *Con riferimento
alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo contenuto, gli eventuali
allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
sarei comunque grato se potesse darmene notizia. This email is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. We remind that - as provided by European Regulation 2016/679
“GDPR” - copying, dissemination or use of this e-mail or the information
herein by anyone other than the intended recipient is prohibited. If you
have received this email by mistake, please notify us immediately by
telephone or e-mail.*
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
