Thanks for the advice from Paul and Tim.<br><br>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. 

<br><br>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?)

<br><br>(1) The UDT model<br><br>create table image_states { state_code text, state_name varchar(20), aerial_photo pgraster, boundary geometry, ...};<br><br>Then there are some records in this table, each one of which denotes one states in USA. 

<br>--------------------------------------------------------------<br>00001 | Utah | {pgraster} | {geometry}<br>--------------------------------------------------------------<br>00001 | Texas | {pgraster} | {geometry}<br>

--------------------------------------------------------------<br><br>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:<br><br>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.

<br>Such as <br><br>Select Export2JPEG('image_states', 'imagedata', 'state_name='Utah''); <br><br>I know it works but I don't think it is clear and acceptable for end users. <br><br>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. 

<br><br>That's some other advantages to use UDT rather than merely relational model. <br><br>Just my opinion :-) <br><br><br><div><span class="gmail_quote">On 7/12/07, <b class="gmail_sendername">Tim Keitt</b> <<a href="mailto:tkeitt@gmail.com">

tkeitt@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 7/11/07, Paul Ramsey <<a href="mailto:pramsey@refractions.net">

pramsey@refractions.net</a>> wrote:<br>> More specifically, there is a lot of talk about "user defined types" in<br>> this document, but the model does not really require any -- the whole<br>> thing can be done with relations.  Doing it as UDT's requires lots of

<br>> book-keeping code for accessors to the properties of the types, doing it<br>> as relations does not.<br>><br>> The same thing could be said about geometry, of course, but the<br>> difference is that geometry objects have a unitary structure that only

<br>> makes sense in aggregate, so breaking them up is wasteful -- you have to<br>> put them back together again before they are useful.<br>><br>> This is less true of these georasters, and in fact they will be somewhat

<br>> broken up anyways, into bands, for example.  Why not start this process<br>> by building the whole thing as a relational model and then see what<br>> doesn't work well and needs a UDT for efficiency?<br>

<br>That sounds like it could simplify things and perhaps speed up a<br>prototype implementation. Xing -- what do you think?<br><br>THK<br></blockquote></div>