Should MVT tiles currently work?

[migurski]

TO REPRODUCE THE ISSUE, FOLLOW THESE STEPS:

Sample scene file excerpt:

import: https://mapzen.com/carto/refill-style/4/refill-style.yaml

sources:
    _dots:
        type: MVT
        url: "{z}/{x}/{y}.mvt"
        max_zoom: 14

RESULT:

Console log errors like:

Tangram v0.11.6 [warn]: tile load error(s) for _dots/15/2639/6359/14: skip@https://mapzen.com/tangram/0.11/tangram.min.js:7:8933
readFields@https://mapzen.com/tangram/0.11/tangram.min.js:7:5731
r@https://mapzen.com/tangram/0.11/tangram.min.js:8:17905
n@https://mapzen.com/tangram/0.11/tangram.min.js:8:15787
readFields@https://mapzen.com/tangram/0.11/tangram.min.js:7:5697
r@https://mapzen.com/tangram/0.11/tangram.min.js:8:15739
value@https://mapzen.com/tangram/0.11/tangram.min.js:13:30641
https://mapzen.com/tangram/0.11/tangram.min.js:13:21897
s@https://mapzen.com/tangram/0.11/tangram.min.js:2:8838
https://mapzen.com/tangram/0.11/tangram.min.js:2:8960
l@https://mapzen.com/tangram/0.11/tangram.min.js:1:31540
promiseReactionJob@[native code]

EXPECTED RESULT:

Dots matching what I’m seeing with GeoJSON tile content.

ENVIRONMENT:

Tangram v0.11.6, Safari Version 9.1 (11601.5.17.1), OS X 10.11.4 (15E65). The tiles are generated with Tippecanoe 1.15.1.

A sample tile response: http://mike.teczno.com/img/tangram-sample-tile-12-2637-6358.mvt

[nvkelso]

@migurski

I'd expect something more like:

import: https://mapzen.com/carto/refill-style/4/refill-style.yaml

sources:
    _dots:
        type: MVT
        url: http://mike.teczno.com/img/tangram-sample-tile-{z}-{x}-{y}.mvt
        max_zoom: 14

or

import: https://mapzen.com/carto/refill-style/4/refill-style.yaml

sources:
    _dots:
        type: MVT
        url: localhost:80/path/to/tiles/{z}/{x}/{y}.mvt
        max_zoom: 14

And check if your tiles are MVT or GeoJSON format (the extensions and type will need to match).

[migurski]

I tried making the URL fully-qualified and got the same errors in the console:

sources:
    _dots:
        type: MVT
        url: "http://127.0.0.1:5000/{z}/{x}/{y}.mvt"
        max_zoom: 14

So that didn’t help. I know that the data source works, because this is displaying dots correctly:

sources:
    _dots:
        type: GeoJSON
        url: "{z}/{x}/{y}.json"
        max_zoom: 14

[nvkelso]

Kerby dots!

…

On Mon, Jan 9, 2017 at 10:02 PM, migurski ***@***.***> wrote: I tried making the URL fully-qualified and got the same errors in the console: sources: _dots: type: MVT url: "http://127.0.0.1:5000/{z}/{x}/{y}.mvt" max_zoom: 14 So that didn’t help. I know that the data source works, because this is displaying dots correctly: sources: _dots: type: GeoJSON url: "{z}/{x}/{y}.json" max_zoom: 14 [image: screen shot 2017-01-09 at 10 01 41 pm] <https://cloud.githubusercontent.com/assets/58730/21795508/3b1d4bb8-d6b7-11e6-9080-70e19b2895ed.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0EO9Mv5wiymFsffvRus8yCZ65s8UL3ks5rQx7vgaJpZM4LfBbB> .

[migurski]

Yeah! 100% copied from Dotspotting down to the colors and radii. :)

[bcamper]

All the Mapzen house styles are driven by Mapzen's MVT tiles, we periodically test against Mapbox-served tiles as well, and some users have created and used their own MVT tiles (Reuters lead map is an example), so yes -- they work.

No one that I'm aware of had tried tiles made with Tippecanoe with Tangram, which made me suspicious. We use Mapbox's own JS PBF decoder (https://github.com/mapbox/pbf) and MVT reader (https://github.com/mapbox/vector-tile-js). The error you are seeing is deep within the PBF decoder, which suggested an issue with the file encoding itself (or not matching the expected schema for decoding).

I noticed we are not running the most recent versions of those libraries in Tangram, so I tried upgrading locally but saw the same errors.

Looking more closely at your file (just eyeballing), it didn't look like what I'm used to seeing from others. I recalled that Tippecanoe outputs MBTiles (so I presume you extracted this from there), and that these are often further compressed w/gzip.

So I tried unzipping your tile file and it now loads fine for me locally.

[bcamper]

Note that when you do render these, you should set collide: false (unless you actually want to make sure they don't overlap at all), and I'm also seeing some weird visual behavior (unrelated to this issue or MVT) that I've documented in #481 and will follow up on there.

[migurski]

Thanks; I had noticed the gzip as well and thought it was a convenience feature of MVT. Looks more like a convenience of MBTiles, maybe something to document as part of mapbox/mbtiles-spec#46.

[migurski]

Also, definitely using collide: false based on Rhonda F's tutorial. My scene file is here if you have any other tips: https://github.com/openaddresses/dotmaps/blob/master/Tiler/templates/scene.yaml

[migurski]

Hm, I tried this with gunzipped MVT content from Tippecanoe. There are no more console errors, but also no data on the map. I tried two methods: decompressing the data and returning it raw, and leaving it compressed but passing a Content-Encoding: gzip header. Both showed identical behavior.

[bcamper]

I suspect you may be missing a layer value in your data source, here: https://github.com/openaddresses/dotmaps/blob/master/Tiler/templates/scene.yaml#L28

When a file that is a single GeoJSON FeatureCollection is served, Tangram treats it as a single-layer data source, and will use that whenever the the source is specified with just data: { source: some-geojson-source }.

MVT always has named layers (even if there's only one), so that behavior currently doesn't apply: you have to explicitly indicate the layer name. I took a look at that file and it looked like it had a layer named dots, so I used that.

For example:

    _dots0:
        data: { source: _dots, layer: dots }

Alternatively, if not data source layer was specified, Tangram will use the scene layer name as a default value (because these often match). So this should also work:

    dots:
        data: { source: _dots }

Give that a try?

[migurski]

Works beautifully, thanks.

[bcamper]

Yay

…

On Wed, Jan 11, 2017 at 2:26 PM, migurski ***@***.***> wrote: Works beautifully, thanks. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABBXaJUvXiTfd21xLCSmXMRyTaqQGQRks5rRSzPgaJpZM4LfBbB> .