tilenol could greatly benefit from the vast majority of tile data servers that are currently unsupported (e.g. Mapbox Tiling Service), and likely to not be supported for a while. In order to provide a simple means of sort of "bridging" this gap, we could potentially implement a new backend data source which allows tilenol to operate as a sort of "frontend" to both raw backend data sources and other tile servers. For example:
layers:
- name: trees
source:
tilejson:
# The backend TileJSON URL
url: https://my.tile.server/tilejson
# The backend layer we want to pull out
layer: trees
- name: buildings
source:
postgis:
...
In this example, tilenol would act as a common "frontend" to both the trees layer (coming from a backend tile server), and the buildings layer (coming directly from PostGIS).
Another interesting thought is that if we were to implement #6 , we could also benefit from the fact that a tilenol server could act as that unified "frontend" for even other tilenol servers, and form a kind of "federated" service.
tilenol could greatly benefit from the vast majority of tile data servers that are currently unsupported (e.g. Mapbox Tiling Service), and likely to not be supported for a while. In order to provide a simple means of sort of "bridging" this gap, we could potentially implement a new backend data source which allows tilenol to operate as a sort of "frontend" to both raw backend data sources and other tile servers. For example:
In this example, tilenol would act as a common "frontend" to both the
treeslayer (coming from a backend tile server), and thebuildingslayer (coming directly from PostGIS).Another interesting thought is that if we were to implement #6 , we could also benefit from the fact that a tilenol server could act as that unified "frontend" for even other tilenol servers, and form a kind of "federated" service.