[WIP] Support tilejson proxy for remote tile provider

[frodrigo]

The goal is to continue using tileserver-gl while the tile source is no more a mbtiles but a remote source described by a remote tilejson.

I done this in pursuing my goal to have a on demand tiles from OpenMapTiles. The remote tiles and tilesjson are here typically from postvers.

This PR add a remote tilejson to the data configuration:

  "data": {
    "v3": {
      "remote_tilejson": "http://postserve:8090/",
      "tilejson": {
        "tiles": [
          "http://a.localhost:8080/openmaptiles/v3/{z}/{x}/{y}.pbf",
          "http://b.localhost:8080/openmaptiles/v3/{z}/{x}/{y}.pbf",
          "http://c.localhost:8080/openmaptiles/v3/{z}/{x}/{y}.pbf"
        ]
      }
    }
  }

It a proxy over the remote tilejson and add the ability to override some part.

This is a working prof of concept. I am not js developer, but I can improve this PR to make margeable if you wish to integrate this new concept.

cc @klokan @nyurik

[klokan]

What is the reason / benefit of proxying requests to TileJSON and .pbfs via TileServer GL?
IMHO it may just add one more HTTP/HTTPS hop...

TileServer GL is a render component - it should be deployed behind a webserver doing a proxy (such as Nginx). This webserver can equally do proxy for a different endpoint with real-time generated .pbfs.

Rendering raster tiles from a remote source is possible already now - by specifying a remote HTTP/HTTPS source inside of the STYLE - pointing it to TileJSON or {z}/{x}/{y}.pbf according to spec from https://docs.mapbox.com/mapbox-gl-js/style-spec/sources/

BTW The OpenMapTiles Postserve is a prototype for real-time serving via ST_asMVT made for the development of the new generation of OpenMapTiles - it was not really intended as a production-ready server for a public map service...

[klokan]

Is there really a benefit in proxying in this case? @frodrigo

[frodrigo]

Just proxy for tilejson, not the pbf tiles.

Defining a remote tilejson in the data from config allow to do replacement of mbtiles://{v3} of the style without no further change to this styles.

So, it make tileserver-gl able to render styles without local tiles and without required to edit style.

I know about the need of front server, particularly to cache tiles (vector/raster), as I render on demand.

(I know about postserv, was just as example)

Actual I am replacing Karthoterian by Tileserver-gl on Makina Maps. I has already implemented this for Karthoterian, but Tileserver-gl better feet the need, except on this point.

[klokan]

Great to hear you are keen on using our OpenMapTiles and TileServer-GL for rendering maps...

The style is in the end not opening local "mbtiles://" - it is opening remote source from "http://...".
It would be confusing for the people, don't you think?

Also, the not proxied tiles from the localhost need to be mentioned in the final URLs in the config...?! Hmm...

Are there other benefits or reasons to do this besides replacing the link in the style.json?

[frodrigo]

The primary goal is to serve style using tilserver-gl, and render png.

About replacing mbtiles:// by http://, yes it's an issue. All the code also name it mbtiles.

The overload of tilejson in my example was only to show it is possible, precisely in the case where there is a frontend server and vector tiles URLs need to be mapped to public URLs.