6 ms·
I love PostGIS. I have used it in many projects. PostGIS raster is really interesting to me but the general sentiment is that it's a bit slow and only use it i
by benboughton1 5y ago
I love PostGIS. I have used it in many projects.
PostGIS raster is really interesting to me but the general sentiment is that it's a bit slow and only use it if you need to. It just seems so powerful to combine raster and vector with SQL. What would the alternative be for raster query vertical and horizontal combined with vector? GRASSGIS Timeseries tools look interesting but I've not tried those. Any other ideas?
- pramsey 5y agoI remain pretty leery of raster in the database, for the reasons you list, but the power of GDAL to reach out over networks for raster access makes me a little more excited about some raster/vector use cases. It's not a panacea, but it's something. https://blog.crunchydata.com/postgis-raster-and-crunchy-bridge https://blog.crunchydata.com/postgis-raster-and-crunchy-brid...
- benboughton1 5y agoI read that blog post. Such a good example. But there is even a comment in there warning about raster via database. I am going to try it out as well with some MODIS data. I wonder what needs to be done to make raster more performant in POSTGIS?
- benboughton1 5y agoI just realised you are the author, so thankyou!
- pramsey 5y agoThere's some work to be done to make all functions parallelizeable. After that it gets harder. For large scale raster analysis, moving the processing closer to the data becomes paramount. I feel like purpose-built raster processing will always be better. Maybe something with FDW or other client/service architecture, where the database sends off the request and the bulk processing happens close to the data. Also, the row-based model of SQL sort of breaks down against raster where the model expects much much larger objects and presenting the tiled-up model to users just adds complexity without getting back performance or flexibility in return.