[postgis-devel] Xing Lin's SoC project (raster support)

[Tim Keitt]

On 7/12/07, Xing Lin <solo.lin at gmail.com> wrote:
> Thanks for the advice from Paul and Tim.
>
> Yes, I also agree pack the information of a georaster dataset into a UDT
> could cost more implementation, attribute accessing overhead. It is also
> possible or even more efficient to just implement it into a pure relational
> model. ESRI ArcSDE did so in this way based on modern relational database.
> But the problem is it might be not so conceptually clear on how to handle
> such data in the spatial database. You might need to heavily rely on the API
> provided by ESRI.
>
> I think the model should firstly meet the way how people think about the
> georaster dataset. The relational model doesn't do well in complicate object
> modelling. People always need the georaster as a single object, because
> conceptually there are integrated as a whole, not broken into pieces.
> That's why we might need a UDT. The following is an examples (which do you
> think is more easier for people to accept your model?)
>
> (1) The UDT model
>
> create table image_states { state_code text, state_name varchar(20),
> aerial_photo pgraster, boundary geometry, ...};
>
> Then there are some records in this table, each one of which denotes one
> states in USA.
> --------------------------------------------------------------
> 00001 | Utah | {pgraster} | {geometry}
> --------------------------------------------------------------
> 00001 | Texas | {pgraster} | {geometry}
> --------------------------------------------------------------
>
> Then I want to have the aerial photo of Utah and export it to JPEG. How
> could I do it? Some functions like the following could be invoked:
>
> Select Export2JPEG(aerial_photo)  from image_states where state_name =
> 'Utah';
>
> Then I can get the outptu in JPEG picture form.
>
> (2) The Relational Model Form
>
> create table image_states { state_code text, state_name varchar(20),
> imagedata BLOB, boundary geometry, ...};
>
> Then there might more than one record in this table denotes the images for
> Utah, because it might already be splited into pieces.
>
> So the same could be done in another way:
>
> Select Export2JPEG(????);
>
> How could we define the parameters for the function Export2JPEG. Mightbe we
> need a table name, image column name and the filter text.
> Such as
>
> Select Export2JPEG('image_states', 'imagedata', 'state_name='Utah'');
>
> I know it works but I don't think it is clear and acceptable for end users.

If the export function was an aggregate, then it could operate on the
set of tiles returned from a query. (How you assemble them efficiently
into a continuous field is I suppose an open question.)

The alternative is to have an external loader/dumper like
shp2pgsql/pgsql2shp from postgis. (ogr2ogr also lets you perform ad
hoc queries and dump to supported formats.)

>
> That's why I try to take the UDT approach. I have done a similar thing in
> relational model which is based on MS OLE DB platform. But when I give it to
> the application developer/end users, they don't know how to use it. Then I
> have to develop a set of API for them to access the data apart from
> database. If we could just do it within one database, it might be helpful
> for the endusers.
>
> That's some other advantages to use UDT rather than merely relational model.
>
> Just my opinion :-)

I think those are good points. Question: does the UDT model
encapsulate the relational model? If so, you could start with the
relational model and then later build the UDT bits around that core.

I'm not against the UDT model per se, just trying to see if we could
find a way to move forward in small steps.

THK

>
>
> On 7/12/07, Tim Keitt < tkeitt at gmail.com> wrote:
> > On 7/11/07, Paul Ramsey < pramsey at refractions.net> wrote:
> > > More specifically, there is a lot of talk about "user defined types" in
> > > this document, but the model does not really require any -- the whole
> > > thing can be done with relations.  Doing it as UDT's requires lots of
> > > book-keeping code for accessors to the properties of the types, doing it
> > > as relations does not.
> > >
> > > The same thing could be said about geometry, of course, but the
> > > difference is that geometry objects have a unitary structure that only
> > > makes sense in aggregate, so breaking them up is wasteful -- you have to
> > > put them back together again before they are useful.
> > >
> > > This is less true of these georasters, and in fact they will be somewhat
> > > broken up anyways, into bands, for example.  Why not start this process
> > > by building the whole thing as a relational model and then see what
> > > doesn't work well and needs a UDT for efficiency?
> >
> > That sounds like it could simplify things and perhaps speed up a
> > prototype implementation. Xing -- what do you think?
> >
> > THK
> >
>


-- 
Timothy H. Keitt, University of Texas at Austin
Contact info and schedule at http://www.keittlab.org/tkeitt/
Reprints at http://www.keittlab.org/tkeitt/papers/
ODF attachment? See http://www.openoffice.org/