[postgis-users] Re: A PostGIS-Raster data proposal

[Guido Lemoine]

Google Earth actually uses a combination of multi-level (pyramidical) image
realisation tiled to small tiles (they recommend 256 by 256). They use
"SuperOverlay" KML to set up the relation between the tiles and levels.
This allow direct access to the individual tiles, without the need for a 
WMS.
Together with (massive) caching this leads to very good performance.

The very nice thing is that you can create SuperOverlays yourself. I managed
to do so (using JAI and JDOM in Java) and am truely amazed with what you
can do (for the moment straight from disk). I easily integrate 100+ Mb 
imagery
from ASTER, LANDSAT, ENVISAT etc. in GE.

WorldWind (NASA's GE Open Source alternative) does something similar,
but using a fixed tile structure and reference. They mention that WMS is 
not
really a workable solution for (massive) access to imagery. WMS with
raster-in-a-database is probably even less so.

Of course, GE doesn't support projections (and many other things we would
like). The pgraster idea is intriguing in specialised image processing 
contexts,
but we can't expect matching performance.

GL

Carl Anderson wrote:

> Now that Paul is up on a soap box I feel compelled to throw my 2 cents 
> in.
>
> I agree with Paul, I have found that is it easier to tune and set up 
> caching for WMS and WC services than it is to try and tune or add 
> caching to database based image sources.  In  mixed client software 
> environments even more so.
> If you believe that the speed of GOOGLE Earth comes from massive image 
> caching you might agree.
>
> The compelling reason to put cell / grid /raster data into PostGIS has 
> to be bound to one or more use profiles.  Each which can be evaluated 
> and understood.
>
> Elevation data comes to mind.  A DEM is a regular gridded set of 
> elevation samples.  Sometimes it is convenient to programmatically 
> convert 2 dimensional LineStrings into 3 dimensional (Z) LineStrings.
>
> Looking at this goal, being able to resample a single elvation from an 
> elevation fabric (source).
> Converting the DEM into a TIN and then representing each polygon in 
> the TIN as a 3D (Z) dimensional plane in PostGIS and creating some 
> sort of resampling function might work better and faster than 
> supporting the original gridded elevation set.  The TIN method 
> actually does run faster in my own tests.
>
> I am looking for a compelling use case to house Raster in a RDBMS.  
> Client centric reasons are not so strong to me.  Reasons compelled by 
> an internal RDBMS issue is stronger.
>
> C.
>
>
>
> Paul Ramsey wrote:
>
>> SDE's raster-in-database support is only faster than other 
>> alternatives because ESRI chooses not to make the alternatives 
>> faster.  If you are ESRI, what's better for you, optimizing 
>> file-based imagery access, or telling people to buy SDE?  Trust me, 
>> if you just want fast access to a large set of imagery, stuff it in a 
>> directory, build a mapserver tileindex on it and serve it as a WMS 
>> service.  Raster-in-database for performance is a red-herring 
>> propogated by ESRI and Oracle who have an interest in selling said 
>> databases -- I have no such interest.
>>
>> Arguments about unified user and access management, and integrated 
>> raster analysis somewhat persuade me, but if people really want this 
>> they are going to need to do it themselves, and job one of that is 
>> creating a design.  I would suggest hitting the wiki, starting to 
>> layout some standard table structures and descriptions of where data 
>> goes, and function signatures for accessing things.  Once a design is 
>> in place, it is possible for folks to take a piecemeal approach to 
>> implementing things a function at a time, but until then nothing much 
>> will happen except jawboning.
>>
>> PS - Copying other people's implementation designs is also 
>> acceptable, though really abstract designs like oracle's georaster 
>> will have a pretty high implementation overhead.
>>
>> PPS - We have avoided having to design anything in the past by simply 
>> aping the standard, but there is no standard to ape in this case.
>>
>> P
>>
>> On 25-Oct-06, at 3:38 PM, galen at shackprices.com wrote:
>>
>>>
>>> I'm not familiar with the specifics of the implementation, but when 
>>> I was
>>> contracting for the EPA in New Orleans cleanup effort, we stored 
>>> massive
>>> multi-gigabyte rasters in a geodatabase using ESRI's (ack!) database
>>> frontend and a MS-SQL backend (it was transparent to users, so it could
>>> have been Oracle).  It made image retrieval much faster over the 
>>> network
>>> and dramatically cut processing time. If we had to build our own 
>>> system,
>>> it would have been more expensive and time consuming.
>>>
>>> Here's a vote of support for the proposal!
>>>
>>> -Galen
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>

-- 

----------------------------------------------------------------
Joint Research Centre, European Commission
Institute for the Protection and Security of the Citizen (IPSC)
Unit: Support to External Security
Via E. Fermi, 1 TP 267 Ispra 21020 (VA), Italy
Tel. +39 0332 786239 (direct line) Fax. +39 0332 785154
WWW: http://ses.jrc.it
----------------------------------------------------------------
Disclaimer:
Views expressed are those of the individual and do not represent the
views of the European Commission