4 ms·

I’ll try my best to explain the process. The data comes from places like the Census Bureau (roads, place names) and then a lot of it has to be collected by the

I’ll try my best to explain the process. The data comes from places like the Census Bureau (roads, place names) and then a lot of it has to be collected by the like of OpenStreetMap/Google/Other Providers. (GIS Data is big business) For Vector based approaches (See mapbox) these data are stored in special built databases and usually simplified geometries are served to the browser. The benefit is continuous zoom, but the pitfall is more server side computation and hence cost. Because of the cost/compute, raster tiles (PNG, jpg, any pixel format) have been much more popular. These start the same, you collect all these data and put them in a database. The difference is the added step of rendering tiles. This one-off computation saves you work from then on. See maps.stamen.com for an example of tiles made from OSM data. And you’re right about place names sometimes not being apparent. This is a trade off when using open data and auto generated tiles. With something like MapBox’s vector tiles, you have individual decimal level control of things like labels. And zoom level is another computational trade off. You start at 0 and define an arbitrary end. The higher the number, the computation/data increases four fold each n. O(4^n) And as far as why the size requirements are so big, geospatial data is big. You have to record information on every point for vectors which depending on quality can be a ton. And for rasters, we’re talking trillions of pixels really. That’s why all of this is server side. And lastly to your point about lightweight desktop software, tiles don’t really have a place in the data process. They’re only really useful for the visualization aspect. And frankly, I think we’re reaching the capacity of the technique, we just might have some headroom in server efficiency.

snodnipper 7y ago
+1 > And lastly to your point about lightweight desktop software, tiles don’t really have a place in the data process. They’re only really useful for the visualization aspect. And frankly, I think we’re reaching the capacity of the technique, we just might have some headroom in server efficiency. Not totally sure what you mean on your last point...data can be feature centric (e.g. stored by feature id) or area centric (stored by area location) etc. Storing data by location is important far beyond visualisation and is abstracted in databases such as PostGIS/Postgres (a branded data structure). That said, I acknowledge that ArcGIS Pro, QGIS etc. have limited support for tiled data but of course that is changing. Safe funded much (all?) of the OGR MVT development afaik.
- bransonf 7y ago
  Oh, I meant more about data analysis. Typically you don’t import raster tiles unless we’re talking about imagery. But as far as like roads and boundaries, you should always work with the raw vectors.
  - kylebarron 7y ago
    This isn't _necessarily_ true, doing data analysis on vector tiles allow for high parallelization. See TileReduce [0] [0]: https://github.com/mapbox/tile-reduce https://github.com/mapbox/tile-reduce
    - bransonf 7y ago
      I meant specifically raster tiles, but this is indeed very cool. I absolutely love what MapBox is doing.
kylebarron 7y ago
> The benefit is continuous zoom, but the pitfall is more server side computation and hence cost. I haven't tested this with dynamic tiles served from PostGIS, but with static tiles served from S3 it's quite the opposite! There's an initial cost to generating tiles, but once they're generated, you can host them on S3 with zero server cost.

snodnipper 7y ago

+1 > And lastly to your point about lightweight desktop software, tiles don’t really have a place in the data process. They’re only really useful for the visualization aspect. And frankly, I think we’re reaching the capacity of the technique, we just might have some headroom in server efficiency. Not totally sure what you mean on your last point...data can be feature centric (e.g. stored by feature id) or area centric (stored by area location) etc. Storing data by location is important far beyond visualisation and is abstracted in databases such as PostGIS/Postgres (a branded data structure). That said, I acknowledge that ArcGIS Pro, QGIS etc. have limited support for tiled data but of course that is changing. Safe funded much (all?) of the OGR MVT development afaik.

bransonf 7y ago
Oh, I meant more about data analysis. Typically you don’t import raster tiles unless we’re talking about imagery. But as far as like roads and boundaries, you should always work with the raw vectors.
- kylebarron 7y ago
  This isn't _necessarily_ true, doing data analysis on vector tiles allow for high parallelization. See TileReduce [0] [0]: https://github.com/mapbox/tile-reduce https://github.com/mapbox/tile-reduce
  - bransonf 7y ago
    I meant specifically raster tiles, but this is indeed very cool. I absolutely love what MapBox is doing.

kylebarron 7y ago

> The benefit is continuous zoom, but the pitfall is more server side computation and hence cost. I haven't tested this with dynamic tiles served from PostGIS, but with static tiles served from S3 it's quite the opposite! There's an initial cost to generating tiles, but once they're generated, you can host them on S3 with zero server cost.