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

[Xing Lin]

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.

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 :-)


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20070712/15844e05/attachment.html>