ThinkGeo.com    |     Documentation    |     Premium Support

MVT and MBTiles problems

#1

I wanted to investigate connecting to a local MVT server by adapting the How-To sample, but couldn’t get anything to render - I can see the tile IDs and wireframe changing as I zoom and pan, but just a plain old solid fill. A quick html-based test with maplibre-gl confirmed the server was set up and serving tiles as expected.

I didn’t see the tile requests incrementing on the server and on investigation it seems the MvtTilesAsyncLayer.SendingHttpRequest never fires so I can’t tell what it’s doing (or not).

Is there any way to tell what it’s trying to do? Or why it’s failing?

Instead I decided to try using the mbtiles files behind the server directly but again, just a blank control. If I select “No Style” I can see the map, albeit in shades of orange. Tried several mbtiles files from different providers, same result every time. The only combination I see working is that shipped in the sample.

Figuring it was the style included in the sample being specific to the tileset, and following the instructions in the documentation, visited Maputnik and without changing anything saved the “Basic” style and tried that. Nothing. Tried several other styles, some crashed the sample immediately or prevented the layer from opening (without an error btw!) which also crashed the sample, but none of them rendered anything.

Is there something special required to get mbtiles styling/rendering working?

Cheers

#2

Hi Kev,

Can you send me

  1. the version of ThinkGeo you are using
  2. the stylejson that works with your data in Maputnik, but not in ThinkGeo

Also can you try XYZ Based Layers -> Display Vector from MVT Server see if they are working fine on your side?

Thanks,
Ben

#3

Hi Ben,

I tried 14.3.2 and 14.4.0-beta73.

I’ve attached the style I saved from Maputnik. The only changes I’ve made are changing the source url (for MVT) and the ‘glyphs’ url (the original required an API key).

basic.zip (2.6 KB)

I did try the XYZ option but it’s (literally) the same as Map Online Data -> MVT :wink:

Cheers

#4

Hi Kev,

Finally I found the reason:

  1. in your stylejson the sources is defined as following
"sources": {
    "openmaptiles": {
      "type": "vector",
      "url": "http://localhost:3000/gb"
    }
  }

MvtAsyncLayer is expecting a json describing the tile link as well as the meta data, such as this: https://tiles.preludemaps.com/data/planet_08032025.json. I bet http://localhost:3000/gb didn’t return the format expected and the layer cannot put up a request URI, thus SendingHttpRequest never fires up.

  1. It’s a bug that the offline layer VectorMbTilesAsyncLayer stops loading the tile when not getting the expected json. It’s been fixed in the latest beta(v14.4.0-beta074)

And just let me know what http://localhost:3000/gb returns if you think it should just work, and we can dig in a big more.

Thanks,
Ben

#5

Thanks Ben,

That endpoint returns json (gb-endpoint.zip (1.4 KB) ). Do you expect an explicit json filename?

I’ve noticed the server I’m using (https://martin.maplibre.org/) doesn’t appear to set “content-type:application/json” to in the response headers either - could that be contributing?

Also tried beta-74 but the MBTiles sample now throws an ArgumentOutOfRangeException in RefreshAsync with : ‘htmlColor (Parameter ‘The color you have provided does not exist.’)’, and MVT crashes in the same method with a NullReferenceException.

Cheers

#6

Hi Kev,

Please pull the latest beta (beta075) which includes the following 2 changes.

  1. Our component had a restriction that the uri in the source must end with “.json”. We’ve verified it’s not necessary and have removed that restriction.
  2. We’ve improved the exception message and have added the input color to the exception message.

Thanks,
Ben

#7

Thanks Ben,

beta-75 has solved my MVT issue and the extended exception info helped track down the problem in the MBTiles style. I now have both working.

For reference, the missing color was ‘hsla(0, 0%, 60%, 0.5)’ - all I had to do was remove the alpha value and make it a plain ‘hsl’.

Thanks for all your help and the quick resolution - much appreciated.

Cheers

#8

Hi Kev,

Thank YOU for letting us know so we can keep improving our products!

This has been fixed in beta-76. Now either ‘hsla(0, 0%, 60%, 0.5)’ or ‘hsla(0, 0%, 60%, 50%)’ would work. Please have a try.

Thanks,
Ben