3 ms·

There's a reason why it is not being done - you wouldn't be satisfied with the speed. Try some old-fashioned GIS application, that queries and displays exactly

There's a reason why it is not being done - you wouldn't be satisfied with the speed. Try some old-fashioned GIS application, that queries and displays exactly what you have selected and compare that with Google Maps. These map apps with cached tiles (whether raster or vector, doesn't matter) gain speed precisely because they limit what the user can choose and then cache that. The normal GIS apps cannot do that, but conversely, their users are complaining that Google Maps is much faster...

maxerickson 10y ago
I would think that vector tiles + display filtering would be roughly just as fast as vector tiles without any filtering. At least assuming a halfway decent implementation (it shouldn't take real long to process the few hundred items that would be present in the viewport).
- Bedon292 10y ago
  You certainly could filter what you receive in the vector tile. However that vector tile is already a cached / filtered piece of the data. It limits what you would be able to do.
  - maxerickson 10y ago
    Sure, the client can only filter the data it receives. But the tiling approach and client side filtering can clearly be applied to POIs, and while I haven't actually experimented with such a thing, I would expect the performance to be quite good even if the user had lots of filters set.
int_19h 10y ago
Correct me if I'm wrong, but doesn't MapBox with vector tiles essentially cache and serve the raw GIS data (in PBF format) on a tile by tile basis, and then render that on the client?
- vetinari 10y ago
  No, it's not raw GIS data. Even the vector tiles are generated for a certain scales (or set of scales). They contain only data that should be displayed at given scales and also the geometries are being generalized depending on the zoom level. What Mapbox can do, is to _remove_ data that are not in stylesheet - but as I understand it, that is being done server side (https://www.mapbox.com/blog/style-optimized-vector-tiles/ https://www.mapbox.com/blog/style-optimized-vector-tiles/). So in theory you could put more data into generated tiles, users could create their customized stylesheet (would have to be found out how, the server needs to have it accessible, it does processing based on it) and it could work - for a few of them. If everyone would do it, you are back to square one. This is usually usable for a defined roles (what group can see what in your data), not for picking and choosing every possible object at arbitrary scale. The thing is, you usually cannot put all the data in the tiles and just serve them - most users won't use them anyway, so you would just waste bandwidth. That one guy who wants something special usually wants other object than that second guy, who wants also something special.
  - maxerickson 10y ago
    Mapbox does maintain a set of (more?) complete OSM vector tiles, aimed at quality assurance tasks: https://www.mapbox.com/blog/osm-qa-tiles/ https://www.mapbox.com/blog/osm-qa-tiles/
  - int_19h 10y ago
    How much bandwidth is actually wasted? i.e. if you were to put all data that's currently in OSM, just chunked into tiles, how much bandwidth would be required to serve it? It would seem to me that, as pipes get thicker and bandwidth keeps growing, we will inevitably hit the point where it's easier to just server raw data and let the client render it soon enough.

maxerickson 10y ago

I would think that vector tiles + display filtering would be roughly just as fast as vector tiles without any filtering. At least assuming a halfway decent implementation (it shouldn't take real long to process the few hundred items that would be present in the viewport).

Bedon292 10y ago
You certainly could filter what you receive in the vector tile. However that vector tile is already a cached / filtered piece of the data. It limits what you would be able to do.
- maxerickson 10y ago
  Sure, the client can only filter the data it receives. But the tiling approach and client side filtering can clearly be applied to POIs, and while I haven't actually experimented with such a thing, I would expect the performance to be quite good even if the user had lots of filters set.

int_19h 10y ago

Correct me if I'm wrong, but doesn't MapBox with vector tiles essentially cache and serve the raw GIS data (in PBF format) on a tile by tile basis, and then render that on the client?

vetinari 10y ago
No, it's not raw GIS data. Even the vector tiles are generated for a certain scales (or set of scales). They contain only data that should be displayed at given scales and also the geometries are being generalized depending on the zoom level. What Mapbox can do, is to _remove_ data that are not in stylesheet - but as I understand it, that is being done server side (https://www.mapbox.com/blog/style-optimized-vector-tiles/ https://www.mapbox.com/blog/style-optimized-vector-tiles/). So in theory you could put more data into generated tiles, users could create their customized stylesheet (would have to be found out how, the server needs to have it accessible, it does processing based on it) and it could work - for a few of them. If everyone would do it, you are back to square one. This is usually usable for a defined roles (what group can see what in your data), not for picking and choosing every possible object at arbitrary scale. The thing is, you usually cannot put all the data in the tiles and just serve them - most users won't use them anyway, so you would just waste bandwidth. That one guy who wants something special usually wants other object than that second guy, who wants also something special.
- maxerickson 10y ago
  Mapbox does maintain a set of (more?) complete OSM vector tiles, aimed at quality assurance tasks: https://www.mapbox.com/blog/osm-qa-tiles/ https://www.mapbox.com/blog/osm-qa-tiles/
- int_19h 10y ago
  How much bandwidth is actually wasted? i.e. if you were to put all data that's currently in OSM, just chunked into tiles, how much bandwidth would be required to serve it? It would seem to me that, as pipes get thicker and bandwidth keeps growing, we will inevitably hit the point where it's easier to just server raw data and let the client render it soon enough.