Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!alberta!calgary!ctycal!ingoldsb From: ingoldsb@ctycal.COM (Terry Ingoldsby) Newsgroups: comp.graphics Subject: Re: What does/should a image DBMS look like? Summary: GIS DBMS Message-ID: <360@ctycal.UUCP> Date: 22 Jun 89 14:21:06 GMT References: <14791@pasteur.Berkeley.EDU> Distribution: na Organization: The City of Calgary, Ab Lines: 62 In article <14791@pasteur.Berkeley.EDU>, aoki@postgres.Berkeley.EDU (Paul M. Aoki) writes: > Image processing folks and SciViGuys: > > As someone with a database background but no experience with what > Real Image Processing people do, I'd like to hear what kind of > services and interfaces you folks would like from your data managers. > > Let's say you could store your binary data in a "real" DBMS -- > one that provided transactions, multiuser access, a query language, > a programming language interface, etc., like the commercial relational > systems do, as well as (say) version control, user-defined functions .... > *** Would you want to see: > DBMS server on frontend, client on supercomputer? > DBMS and client on supercomputer? > something else? ..... > *** Would you want to see: > DBMS server communicating through (embedded) query language > with the application, with the application explicitly > negotiating for chunks of data (bytes, pages, ..) > DBMS server communicating through IPC with the application, > with the application explicitly negotiating for chunks > of data (bytes, pages, ..) > performing computation in the DBMS server process using > user-defined functions (as in the example), with the > function controlling I/O in a loose way by a mechanism > like (say) the C standard I/O library > something else? > > *** What else would you like to see? > I'm sure that each application area will have some conflicting needs. Hopefully if we all tell you what we need, you can figure out the commonality across applications. I work with Geographic Information Systems (GIS). My particular GIS involves municipal mapping, so we have streets, parcels (lots of land), fire hydrants, bus stops, and so on. We also know (or find out) things like average age of population in an area. To effectively manipulate our data we need to be able to make queries like: - Show me all the areas where the average age is < 35 that are over 5 km from a swimming pool. - List all parcels of land that are served by bus route 44. You get the idea. If you can satisfy these queries AND get the graphics or text on the screen quickly then the world will beat a path to your door. As for the hardware environment, more and more the GIS world is moving towards workstations networked to central file servers and plot servers. Also bear in mind that many people will be accessing the database concurrently. Easy, eh!? -- Terry Ingoldsby ctycal!ingoldsb@calgary.UUCP Land Information Systems or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb