<br><font size=2 face="sans-serif">IMO:</font>
<br>
<br>
<br><font size=2 face="sans-serif">Thanks for the reply Arnulf.<br>
<br>
</font><font size=2><tt><br>
> <br>
<br>
> I tell <br>
> her that she has been brain washed by certain creative minds who <br>
> "sell things" (instead of develop software) into thinking
that files<br>
> based systems are stone age. She hates me for it and curses her <br>
> vendors at the same time now... There are arguments for file based
<br>
> approaches, one of them is that hardware is still developing really
<br>
> fast. Even disk read head caches are part of the spatial data <br>
> infrastructure. It is just a question on whether you make use of <br>
> them. </tt></font>
<br>
<br><font size=2><tt>Each person/organisation has their own problem space
for managing spatial data. Some are working with large amounts of data
over a large regional area where they want consistant data delivered. For
others, they are only interested in working with a small subset of data
for a particular analysis. There are countless other uses in between.</tt></font>
<br>
<br><font size=2><tt>For many uses, a database makes sense, for others
a file based approach makes sense.</tt></font>
<br>
<br><font size=2><tt>I'm not trying to force you down one track, make your
own choice based on your needs.</tt></font>
<br>
<br><font size=2><tt>wrt brainwashing, I like to think that I'm healthily
sceptical of vendors and OS claims alike. I prefer to have a good look
at a solution and make up my own mind. My experiences tell me that the
use of a database for managing spatial data (either vector or raster) is
the right approach ...... for my problem space.</tt></font>
<br>
<br><font size=2><tt><br>
> > <br>
> > I've implemented and managed a number of ArcSDE instances over
the years. <br>
> > As skeptical as I am about the decision to rename the product
as ArcGIS <br>
> > Server basic (or whatever its called now), ESRI have done a great
job with <br>
> > the product. Particularly with its integration with ArcGIS Desktop
as the <br>
> > primary user interface for adding, maintaining and managing spatial
data <br>
> > from a GUI. You don't need to use SQL, but it also has its advantages
<br>
> > (when appropriate).<br>
> <br>
> This should probably rather read "with ArcGIS Desktop as the
*only* <br>
> user interface" - which makes you depend on that vendor. I would
<br>
> amend the second part to read "Unfortunately you can't use SQL,..."
<br>
> but thats also just a personal opinion.</tt></font>
<br>
<br><font size=2><tt>This is partly true as I understand it. You can use
ArcSDE command line tools, Python Scripts, SQL and there may be scope for
WFS-T in the future for maintaining data. There are also a number of OSGeo
apps that can read ArcSDE.</tt></font>
<br>
<br><font size=2><tt>A lot depends on how closely you want to follow ESRI's
recommendations and directions (and how much you value the integrity of
your data). My personal preference is to take advantage of the benefits
of multi-versioned editting of spatial data using ArcSDE and ArcGIS, but
to deliver the data and develop applications around the use of Open Standards.
I'm currently looking at the use of OS Spatial apps to serve this data.</tt></font>
<br>
<br><font size=2><tt>I'm also monitoring OSGeo apps for potential future
desktop use (GRASS springs to mind).</tt></font>
<br><font size=2><tt><br>
<br>
> <br>
> Just to make sure: "corporate database environment" refers
to any <br>
> database software, not just Oracle? SDE is not a corporate database
<br>
> environment or do you see it as a part of it? </tt></font>
<br>
<br>
<br><font size=2><tt>These are generic comments relating to the use of
a database.</tt></font>
<br>
<br><font size=2><tt>Yes you are correct. ArcSDE can be thought of as an
interface that controls access to the data stored in the underlying database.</tt></font>
<br>
<br>
<br><font size=2><tt><br>
> <br>
> > - Within a large organisation, it is possible to get rid of most
of the <br>
> > islands of data that are hidden in a wide variety of departments.
If <br>
> > implemented right, people come to see the database as the authoritive
<br>
> > source of their data and respect it as such.<br>
> <br>
> Yes. But you would not want to have people talk to the database (ugh<br>
> - SQL) but rather to a service. Give people a link to a service <br>
> instead of a file to store on their own machine. There is no <br>
> explicit need for a database, just encapsulate whatever you have <br>
> behind a service. Users don't care what is behind the service, it
<br>
> can be a database or a lump of files on a SAN. </tt></font>
<br>
<br><font size=2><tt>Yes. You want an interface between yourself and the
DB. But there are use cases for controlled access via SQL (as long as the
integrity of you data is assured).</tt></font>
<br>
<br>
<br><font size=2><tt><br>
> <br>
> > - This can remove the situation where you get multiple copies
of the same <br>
> > dataset around your organisation, with different people making
their own <br>
> > independent edits to the data and expecting someone to reconcile
the edits <br>
> > with the authoritative data set at a later time (if you're lucky).<br>
> <br>
> Absolutely. But I fail to see the need to store rasters in a <br>
> database arise from this argument.</tt></font>
<br>
<br>
<br><font size=2><tt>See my earlier description of state wide mosaics with
regular updates.</tt></font>
<br><font size=2><tt><br>
> <br>
> > - It can also remove the situation where someone takes a copy
of a <br>
> > critical data set and does not update it for several years, leaving
<br>
> > business people making critical decisions on suspect data.<br>
> > <br>
> > - You can start managing your data for a given geographic phenomena
as a <br>
> > single entity covering a large geographic region, without having
to resort <br>
> > to tiles and all the related edge matching problems that we had
in the <br>
> > past (e.g. mismatching pixels, lines, polygons that just end
at the tile <br>
> > boundary or have an incorrect attibute on the matching sheet
etc). <br>
> <br>
> I am probably too vector oriented to understand the problems <br>
> involved here but my experience is that there should be no issue if
<br>
> you have your services configured all right. <br>
> </tt></font>
<br>
<br><font size=2><tt>I don't agree. But then my requirements are for spatial
data that covers a large geographic area and is used by many people in
a corporate environment. </tt></font>
<br>
<br><font size=2><tt>SOA, while it has definite advantages does not provide
all of the answers.</tt></font>
<br>
<br>
<br><font size=2><tt><br>
> > - Some of the biggest advantages though, come from the corporate
IT <br>
> > support that you come to rely on, e.g. regular backups, large
disk <br>
> > capacity on fast SAN devices, secure access to data by authorised
<br>
> > custodians, redundant databases for disaster recovery, point
in time <br>
> > restoration of data etc.<br>
> <br>
> But there is no difference whether you back up files or a database.
<br>
> Well, actually there is a difference. Backing up files is a lot <br>
> easier, more robust and much much better scalable than cramming <br>
> everything into one or even several databases and trying to <br>
> replicate that once it needs to be scaled up.</tt></font>
<br>
<br><font size=2><tt>Two examples:</tt></font>
<br>
<br><font size=2><tt>- One day in December last year, I needed to restore
a dataset as it was at 11am the previous day to save some maintenance people
a weeks work in recreating their data. We were able to do this.</tt></font>
<br>
<br><font size=2><tt>- Several years ago, we had a major power outage that
took out several disks in our SAN. The disks just happened to contain all
of our spatial data. We had services back up and running in several hours
by cranking up our DR database.</tt></font>
<br>
<br>
<br><font size=2><tt>Thanks for the debate. But all said, if a database
doesn't meet your use case, don't use it.</tt></font>
<br><font size=2><tt><br>
</tt></font>
<br><font size=2><tt>Bruce</tt></font>
<br>
<br>
<br>
<br>
<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>