rinigus / mapbox-gl-qml

Unofficial Mapbox GL Native bindings for Qt QML
GNU Lesser General Public License v3.0
38 stars 10 forks source link

add ability to transform URL #17

Closed rinigus closed 7 years ago

rinigus commented 7 years ago

Requires exposure of ResourceTransform by Qt bindings (issue has been filed)

tmpsantos commented 7 years ago

Why was this needed in the first place?

rinigus commented 7 years ago

I am porting Poor Maps (https://github.com/otsaloma/poor-maps) application over to Mapbox GL and it supports several maps servers. One of the map servers is setup by Poor Maps author - @otsaloma - has setup a map server that provides map tiles for his users. That particular server has an api key added to URL via ?apikey=XXXX , similar to Mapbox access token setup. So, by ability to add any string in the end of requested URL, we can support servers requiring such keys.

In QML, I expose it via urlSuffix property. In addition, I found it helpful for debugging to print out all requested URLs on stdout (if urlDebug property is set to true). These both properties are evaluated on each URL request in QML plugin and can be changed on fly (requiring thread safety though).

tmpsantos commented 7 years ago

Hmmm, that could still be done without the URL transform API. The Mapbox plugin was never vendor locked to the Mapbox servers. You need to create a custom style pointing to a tile source outside the Mapbox servers using http[s]:// schema instead of mapbox://.

rinigus commented 7 years ago

Re vendor locking: sure, as far as I understand, I can even replace mapbox:// with some other http[s]:// address. The locking was never implied, sorry if it felt that way.

As for how to incorporate requests with custom URL, I don't know. In this case, API key is used for fetching style itself, fonts, and data (pbf). I am a beginner with Mapbox GL and would probably have to look into changing tile request URLs if needed.

Also, from the look into APIs for Android and iOS, such URL transform API was missing for Qt. Hence this implementation.

tmpsantos commented 7 years ago

The locking was never implied, sorry if it felt that way

No need to apologize. And I did not read as it was implied.

In fact, our docs lack explanation on how to use our tech with 3rd party servers. When you request a style, say, https://example.com?style=mystyle?key=123456, the style returned should have in the body something like:

"my_vector_tyle_base_layer": {
  "type": "vector",
  "url": "https://example.com/base_layer.tilejson?key=123456"
}

The base layer follows the TileJSON spec. That should point to the actual tile hosting:

"tiles": [
    "https://example.com/tiles/{z}/{x}/{y}.mvt?key=123456"
]

So the hosting service will generate the urls on the fly. I think the good thing of using the URL transform is that the key won't go to the URL that get's cached, so changing your key won't invalidate the cache.