<br><font size=2 face="sans-serif">IMO:</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Hi Tyler,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the reply.</font>
<br>
<br>
<br><font size=2><tt>> Am I correct in believing that the two things
people desire with <br>
> images in an RDB, is having an abstract 1) storage framework
<br>
> (tables) and </tt></font>
<br><font size=2><tt>> 2) a common access language (SQL) for managing
the <br>
> framework. You could have the most complex storage set up behind
<br>
> the scenes, but as long as the access interface plays well, the <br>
> complexity could be minimised by good UI design. At least I
think <br>
> so, but haven't done it before.</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>I can't speak for other people's needs, but only give
my own opinion.</tt></font>
<br>
<br><font size=2><tt>My experience with storing spatial data in a database
is mainly limited to ESRI's solutions based on ArcSDE/Oracle (~7 years).
I have had a cursory look at Oracle Spatial and PostGres/PostGIS and intend
looking a lot closer at both. I've also used a number of spatial tools
over the years from a number of vendors.</tt></font>
<br>
<br><font size=2><tt>I've implemented and managed a number of ArcSDE instances
over the years. As skeptical as I am about the decision to rename the product
as ArcGIS Server basic (or whatever its called now), ESRI have done a great
job with the product. Particularly with its integration with ArcGIS Desktop
as the primary user interface for adding, maintaining and managing spatial
data from a GUI. You don't need to use SQL, but it also has its advantages
(when appropriate).</tt></font>
<br>
<br><font size=2><tt>I've found a number of benefits with managing spatial
data in a corporate database environment. These comments apply to both
vector and image data. I'm sure that these comments are equally pertinent
to most RDBMS maintained spatial data. Some examples are: </tt></font>
<br>
<br><font size=2><tt>- Within a large organisation, it is possible to get
rid of most of the islands of data that are hidden in a wide variety of
departments. If implemented right, people come to see the database as the
authoritive source of their data and respect it as such.</tt></font>
<br>
<br><font size=2><tt>- This can remove the situation where you get multiple
copies of the same dataset around your organisation, with different people
making their own independent edits to the data and expecting someone to
reconcile the edits with the authoritative data set at a later time (if
you're lucky).</tt></font>
<br>
<br><font size=2><tt>- It can also remove the situation where someone takes
a copy of a critical data set and does not update it for several years,
leaving business people making critical decisions on suspect data.</tt></font>
<br>
<br><font size=2><tt>- You can start managing your data for a given geographic
phenomena as a single entity covering a large geographic region, without
having to resort to tiles and all the related edge matching problems that
we had in the past (e.g. mismatching pixels, lines, polygons that just
end at the tile boundary or have an incorrect attibute on the matching
sheet etc). </tt></font>
<br>
<br><font size=2><tt>- Some of the biggest advantages though, come from
the corporate IT support that you come to rely on, e.g. regular backups,
large disk capacity on fast SAN devices, secure access to data by authorised
custodians, redundant databases for disaster recovery, point in time restoration
of data etc.</tt></font>
<br>
<br>
<br><font size=2><tt>To date, I have not found a suitable solution for
managing imagery that includes multi and hyper spectral data in a database.
But I'm looking.</tt></font>
<br>
<br>
<br>
<br><font size=2><tt>Ideally the solution will use open data formats for
storage and delivery. I'm getting sick of having to redevelop corporate
applications with the same functionality because a vendor has decided to
change their technology and data formats. This results in a lot of wasted
time and money that would be better used implementing effective decision
support tools that allow businesses to better understand and exploit their
data. </tt></font>
<br>
<br><font size=2><tt><br>
<br>
> <br>
> Some more recent raster in db discussion here:<br>
> http://spatialgalaxy.net/2008/02/15/rasters-in-the-database-why-bother/<br>
> <br>
</tt></font>
<br><font size=2><tt>Thanks for the heads-up Tyler. I obviously don't know
what I'm talking about ;-) (eh Tim?).</tt></font>
<br>
<br>
<br><font size=2><tt>Bruce</tt></font>
<br>
<br>
<br><font size=2><tt><br>
</tt></font>
<P><FONT face=Arial size=2>Notice:</FONT><FONT
style="BACKGROUND-COLOR: #ff0000"><BR></FONT><FONT size=2><FONT face=Arial>This
email and any attachments may contain information that is personal,
confidential,<BR>legally privileged and/or copyright.</FONT> <FONT face=Arial>No
part of it should be reproduced, adapted or communicated </FONT><FONT
face=Arial>without the prior written consent of the copyright owner.
</FONT></FONT></P>
<P><FONT size=2><FONT face=Arial>It is the responsibility of the recipient to
check for and remove viruses.</FONT></FONT></P>
<P><FONT face=Arial size=2>If you have received this email in error, please
notify the sender by return email, delete it from your system and destroy any
copies. You are not authorised to use, communicate or rely on the information
contained in this email.</FONT></P>
<P><FONT face=Arial color=#008000 size=2>Please consider the environment before
printing this email.</FONT></P>
<P><FONT face=Arial size=2></FONT> </P>
<P> </P>
<P> </P>