4

I'm building a web application, which involves (currently) a REST backend and a frontend SPA. The backend is hosting massive geo-enabled data, and the frontend is displaying it on a mapbox map. I'm hitting performance issues, because of the stack I set up. Here's the stack, when it comes to displaying a map.

    MapboxGl.js player
        ^          ^
        | (HTTP)    \
 Node.js backend     Mapbox APIs vectors
        ^
        |
     MongoDB

The HTTP endpoints serve both GeoJSON and REST data. The GeoJSON part is dynamically generated from a set of MongoDB collections (say, gpspoints, images, lines etc.). The Mapbox API is my Mapbox Studio style.

I'm looking for the best alternative to this design. And reading about maps, vectors, tiles, rendering and stuff, I came up to the idea that I should trade my GeoJSON server for a Vector tiles server (only for the map part). I'd like to end up with something like.

         MapboxGl.js player
       ^         ^           ^
      /          | (HTTP)     \
Vector tiles  Node.js backend   Mapbox APIs vectors
   Server            ^
     ^               |
     |               |
Other backend ?   MongoDB

I'm struggling at the point of making design choices. The questions I have in mind are :

About generating :

  • I came to the idea that I must generate my vector tiles from a GeoJSON. Is that correct ? Would it be possible to generate vector tiles from scratch, I mean, say, from a node.js routine script, parsing datas from various sources (.csv, other databases, etc.) and make operations on it (using turf.js), then generating vector stuff, like pushing, maybe updating, deleting, etc ?
  • I found geojson-vt which seems to be able to translate GeoJSON to vector tiles, but only in json format. I found vt-pbf, am I on the right direction ?

About serving

  • Once I would have been able to generate whatever-format-vector-tile, I am going to be willing to serve it. I found Tilelive.js which seems very good, and has plenty of modules, including backend ones. Is that a good option ?
  • Speaking generaly, would it be possible not to generate any static file stuff, and maybe dynamically serve any-vector-format from a database, through something like tilelive ?

Additional info :

  • My datas are "mutable", but I have routine scripts that run at night and parse new datas. Thus, live-map-displayed-data mutability is not a requirement : I can update / re-parse a whole dataset at night to serve it on the morning
  • Both generating and hosting on Mapbox studio is not an option, since my data is critical and must be hosted in specific coutries. A self-hosted option is mandatory, any cloud-based stuff is not ok :/

This question is redundated in softwareengineering.stackexchange

1 Answer 1

3

I had good results following this tutorial on using tippecanoe to generate compressed protobuffer vector tiles.

I just use Amazon S3 for hosting, but for your application a dedicated server running Nginx with a memory cache in front would work well.

You can certainly generate vector tiles on the fly, but if your data is not dynamic enough it's probably not worth the processing overhead.

3
  • Thanks about the whole-chain tutorial :) I'll digg into it. Do you know any node.js-based Tippecanoe alternatives ? Commented Sep 20, 2017 at 8:10
  • Concerning a dedicated server running Nginx with a memory cache in front. Do you mean using Tilelive with some modules ? Like the Redis one ? I might be missing something, but serving a raw .mbtiles .pbf or something file isn't enough to efficiently display vector tiles on a map, there should be some kind of mecanism that query the file ? Commented Sep 20, 2017 at 8:11
  • You can certainly generate vector tiles on the fly, could you provide an example ? Or maybe juste some paths that I can follow ? Modules or something Commented Sep 20, 2017 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.