GeoTrellis Server Enhancements

[pomadchin]

This issue describes possible questionable GeoTrellis Server design parts. The goal of this issue is to describe concerns and possible steps towards making GeoTrellis Server more a library and less an example / "demo" project.

General comments

Package names and implicits locations can be revisited. At this point i.e. we have a vlm package and both the name and the contents of it are not aligned with the current GeoTrellis release.

Core

Packages structure

• vlm package - Do we need it at all? If we need it, than there is probably a better location for functions located in this package
• geotrellis.server.vlm.geotiff.GeoTiffNode - not a part of the core, it is more an implementation which is never used (only in the examples project)
• gtlayer package - not a real part of the core as well, it is more an example of how to implement "Reification" (in terms of GeoTrellis Server project) typeclasses.
• extent package - contains a solid piece of functionality, if it is used, should we move it into the geotrellis core? If not, is there a better place for it?

Core types and functions

• ExtentReification, and TmsReification - We can consider better names for these core typeclassed and provide an appropricate syntax to work with them, so it would not be that implicit as it is right now.
• HasRasterExtents - Do we need this typeclass? if we do, may be a better name and some syntax around it may help to undersntad it.
• LayerExtent, LayerTms, LayerHistogram - Is there a better place for these functions? Can syntax packages for TypeClasses help with understanding of what these functions do?
• store.query package probably should also be reconsidered and implicits related to the query syntax can be placed into the syntax package as well. Mb Repository is a bad name for repositories? What is a better name for this concept?

UPD:

• After the conversation with @echeipesh: it is possible to make GT Server work with the RasterSources only. In this case we probably don't need all these (Reification) type classes. This would mean to mainline the RasterSourceF and RasterSource = RasterSourceF[Id] (not necessarily though). As a first pass: to try to use the RasterSource interface to get rid of these type casses.
• MAML Refactor?

I general thу core module should address the main goal and feature of the GeoTrellis Server project - add capabilities to serve Rasters using GeoTrellis server and to provide syntax to simplify such services implementation.

The major core project issue is that it is challenging to understand what are ExtentReification, TmsReification, and HasRasterExtents, how to implement them and what functions require them as well as how to use them. It is also unobvious where to search for these type classes instances.

Example (This section should be renamed)

• Can be the simple demo of how the server should be built and how to define all important typeclasses. An example of the core module and the proof that GeoTrellis Server is a library.

UPD:
@echeipesh it should be not an example how to make the service, but it should be an implementation of the service as a CLI tool, and we would be deploying it and using.

Ogc

• In general this project is very scoped already, but would require some changes to be aligned with core.
• Revisit the "View" pattern for the OGC services description: is there a better way to describe OGC services capabilities?

Ogc Example

• Can be removed, since STAC Example covers it, but also supports STAC sources.

STAC Example

Packages structure

• stac.api package would be eventualy moved into the stac4s (Migrate Franklin types to api module stac-utils/stac4s#119)

Core types and functions

• Services description is coupled with the Services configuration and services instantiation.
• Can {WCS|WMS|WMTS}Views live in the ogc package?
• Should the configuration be a part of the core?

The main issue of all the examples projects is that we'll have to copy this configuration template (like it was done for the GeoTrellis PointCloud Server). Configuration should be abstraced and decoupled as much as it is possible from the actual service implementation and parts of it should not leak into how services are created and probebly.

MAML Integeration and decoupling MAML from the configuration

• x_x

Possible plan to tackle this issue

1. Start cleaning up the core package, rethink the core component and its usage.
2. Convert the example project into an independent CLI service.
3. Standartize interfaces on the RasterSource
4. Remove ogc-examples project
5. Decouple the Service Configuration from the Service Implementation.
6. STAC Example project - Can it be a part of a normal CLI? (ogc-cli)
7. Which can require the MAML refactor to use RecSchemes
8. GeoTrellis PointCloud server can be a 'trivial' test.