Loading ...
I’ve come to the conclusion that storing rasters in a database is of dubious value, particularly from a data warehouse perspective.
If you manage a collection of rasters that are updated on a frequent basis, storing them in a relational database with ArcSDE quickly becomes a pain. I’m not talking about a dozen or so rasters, but rather tens of thousands. The overhead of the database and middleware just doesn’t seem to be worth it.
A better solution is to use MapServer with a tile index (created using gdaltindex) to serve them to your desktop clients via WMS. Fast, simple, and easy to update and manage.
I’ve used this approach to serve a few hundred GB of elevation data to desktop client via WCS. It works great… I don’t see why anyone would want the overhead storing of rasters in a RDBMS.
Amen, or as Andre 3000 might say, Ah-lady. Except the bit about WMS. Imagery tiles over HTTP/1.1 (ala Google Maps) is the way to go.
And what if you have so much imagery that the data must span many machines? Then you need something like HDFS: http://zcologia.com/news/683/more-thinking-beyond-the-spatial-rdbms/
Even ESRI knows this is dumb.
http://www.esri.com/software/arcgis/imageserver/index.html
@Sean:
Sometimes your desktop client dictates WMS
@James Fee,
Cool, I wonder how long until people start asking for rasters-in-database purely because it’s an SDE “feature”… probably a long time, since Oracle fed that fire too.
Paul, it will probably take years for folks to get it out of their system.
@Sean: tiles work for static aerial imagery served up under a pre-determined coordinate systems and resolution. What about non-imagery raster data? What about cases where you need the raw data as a contiguous raster? What about resampling methods? Other projections? Resolution? Edge effects? Tiles rarely work for me but I guess if all you need is base aerial photos it would work.
As far as spanning different machines, you could nfs mount them and create a tile index across the different machines. I haven’t tried this
I should know by now that tile == static to most people. I’m just thinking of raster pieces, static or dynamic as needed, served from an HTTP server. WMS and WCS pretty much get the job done, granted, but are smelly. I’ve made the arguments many times in many other places, so here I’ll just say “smelly”.
Could someone comment on the best raster storage and access methods for web geoprocessing? I’m wondering if having the rasters in a database would be good for map algebra functions?
Oracle GeoRaster, ESRI Image Server, seems a puzzling question as to the relevance anymore. The only real value any of these could potentially deliver over simply serving up cached tiles would be in on-demand web-based image analysis and processing, but if this is the case, why not DIPEX or other solutions?
Seems like trying to turn a niche into mainstream when it’s not warranted.
@Josh Campbell, the access method is independent of how you use the image data. Rule of thumb, if somebody recommends storing image data in an rdbms, they don’t know what they are talking about. Yes, there are a few esoteric cases where it may make sense, but that’s far from the norm. IMHO the map algebra function argument only makes sense if the rdbms does the algebra, and for some reason it’s more efficient than doing it on a fat client. What rdbms and what algebra functions did you have in mind?
@Tim, thanks for the info. I can understand the image data argument, but I’m thinking about a hydrologic model that would run through a web application. A user would access a web page that contained a map view of an area and select a location for analysis; a set of independent variables would be created for that location (first step is to derive a watershed boundary for the newly selected point and use that boundary as a mask for subsequent zonal statistics). The watershed delineation requires a digital elevation model and the zonal statistics run on multiple other non-image rasters.
Given the number of vector ‘overlay’ operations now available within the rdbms, I wondered if raster calculations could be structured as sql queries?
Thanks,
@Josh, I can see where you’re coming from, and at first look the sql model does look attractive. I still believe it’s a blind alley though.
What you’re really asking for is a web interface to something like GRASS, and wondering if it wouldn’t be easier to re-implement GRASS in an rdbms to get it. For my money, web enabling GRASS (or equivalent) is the least cost path, even at 100:1.
The best solution I’ve come across so far has been tiles at different resolutions through WMS or WCS, flexibility is the keyword in this case for me…
Hi there, is there any plugin for Qgis which can be utilised to export rasters to Postgis?