How to add the same features to multiple zoom levels in MBTiles (MVT) writer? | Community

I have a very detailed source dataset of buildings and roads. I want to create a an MBTiles file with data on z15 and z17 - our software will automatically overzoom from z15 to z16.

On z15 I want a subset of the features in the dataset to be written (mainly area features, leaving out detailed line features representing roof details and such). On z17, all features should be written.

I have tried to solve this by creating an MBTiles (MVT) writer with two feature types - one for z15 and another for z17. I then route the features accordingly. The layername is created from a value in the feature's attributes.

However when I inspect the result in the newest QGIS, it is not right. On z15, the subset of features are present as expected. On z17, instead of all features, only the features not present in z15 have been written.

So, to summarize, it seems that features written to one zoom level will not be written to another. I think this is in line with the philosophy of vector tiles, so I'm wondering if there's another way to achieve this, or if it is a bug?

fme_mvt2 fme_mvt1

Edit: Attached simple sample data and workspace.

Page 1 / 1

What is the test in the TestFilter and what do you fanout on on the writer?

I think one of those thing are affecting the output (specially the fanout)

What is the test in the TestFilter and what do you fanout on on the writer?

I think one of those thing are affecting the output (specially the fanout)

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

If you disable the z15 writer do all the features end up in the z17 output?

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

Yes, they do.

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

Do you use any attributes that are native to the mbtileswriter. Can you post a sample of your data?

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

I do not use any format attributes belonging to the MBTiles writer.

Unfortunately I cannot share the data I'm currently working on, but I will try to recreate with some open data, and share it here.

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

I was able to reproduce with simpler data and workspace. See attachment.

The TestFilter separates which features go to z15 and which features should go to both z15 and z17. This is determined earlier in the workspace, only based on knowledge of the source data.

As for fanout, I've tried to use a constant string as a fanout expression (such as "output.mbtiles"). This because I want to be able to expand the workspace to use parallel processing later.

I also tried to set the filename directly in the writer (no fanout). This actually resulted in a non-descript error.

Vector MBTiles is still in tech preview. Maybe someone from Safe will put a word in.

I tried different routes but something just doesn't work.

Perhaps you need to create a topology first when you write to vector tiles. IDK

@mbu Thanks for including the sample data and workspace. I've reproduced your issue. It is a known limitation with the MB Vector tile writer . We'll try and get this addressed. Unfortunately, I haven't found a workaround, but I'll keep looking.

Thanks for the effort @caracadrian , I appreciate it.

Good to hear that you're working on the MBTiles writer @Mark Stoakes ! Both my company and our clients are looking forward to switching from our proprietary format to MBTiles. This will enable use to swap out several complicated toolchains with a single FME workspace 👌

Reply