mysql

[Doug Nebert]

mocha wrote:

> basically that was what i was talking about. having a db back end to store 
> the data (points, polygons, features, etc) one can extract that information 
> quickly for what ever purpose. for instance, if i want to do a route from a 
> to b, or find the nearest restaurant to my office etc by zipcode etc.. 
> using lat and long. i'd only need one common db back end. then i can plot 
> all of this to my hearts desire on my map.
> 

It would be very nice to have a database storage methodology that could 
be used against a database, but to invent one that works in all 
databases might not be so easy. You may wish to look into the OpenGIS 
Simple Features Access SQL specification that is supported by several 
vendors. This specifies only the query and result syntax as 
formalizations in SQL letting the backend database do the support work. 
By supporting a standard request interface, multiple databases 
(including SDE and Oracle 8i Spatial) would be supported. Don't let the 
"simple" aspect dissuade you -- it supports the general range of 
geometries present in a shapefile. A similar specification is also 
emerging for raster data (called, ironically, Coverages).

Something to consider in your database storage interfaces.

Doug.





> At 10:32 PM 4/19/00 -0400, Robert Chavez wrote:
> 
> >I've used MapScript with some Perl to build interfaces to PostGreSQL
> >databases  -- using a database of points, polygons, spatial extents,
> >raster images, etc.  Perl and MapScript handle everything quite
> >cleanly and nicely.  So far speed hasn't been an issue.
> >
> >What kind of interfaces did you have in mind?
> >
> >Rob Chavez
> >
> >On Wed, 19 Apr 2000, mocha wrote:
> >
> > > anyone working on interfacing mapserver to an sql db (mysql?). i think 
> > this
> > > would speed it up a little.
> > >
> 
> 
> 
> 



--
Douglas D. Nebert
Clearinghouse Coordinator
FGDC Secretariat	Phone: +1 703 648 4151	Fax: +1 703 648-5755	
Pager Messaging: 	http://clearinghouse3.fgdc.gov/dougmsg.html