<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.0.6619.12">
<TITLE>RE: [mapserver-users] PostGIS or Mysql and GeoMoose.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Nelson,<BR>
David explains my thoughts about the shapefile/performance issue better than I did (in a post that didn't make it to the listserv). In a word, the shapefile and mapserver are optimized to have robust access, so they do the job as well as, or in many cases, better than PostGIS in terms of read-only access.<BR>
<BR>
As for the concept of having one machine serve the shapes, and the other generate the maps, this is a matter of preference. With a Gigabit backplane, I don't see the performance being that much of a problem, but once again, it depends upon the size of the datasets that you will be delivering. Also, it depends on what else the server may be doing, if the web server has many tasks, and you are doing some fairly intensive geoprocessing stuff, it might be a benefit to have the spatial DB on another box.<BR>
<BR>
Of course, all of this comes down to testing on your own setup to find the most optimal configuration. And I have to say that you can't go wrong with providing yourself with the *capability* to provide spatial DB power, and load balancing. That just seems like a smart set of options to keep in your toolbox.<BR>
<BR>
r.b.<BR>
<BR>
-----Original Message-----<BR>
From: mapserver-users-bounces@lists.osgeo.org on behalf of Fawcett, David<BR>
Sent: Tue 5/13/2008 9:55 AM<BR>
To: Nelson Soto; mapserver-users@lists.osgeo.org<BR>
Cc: <BR>
Subject: RE: [mapserver-users] PostGIS or Mysql and GeoMoose.<BR>
<BR>
I would be surprised if you actually get a performance gain from using a<BR>
spatial db over a well optimized (tiled, indexed, overviews) set of<BR>
shape files. Using the spatial db definitely gives you some more<BR>
flexibility, but I would doubt that it would out perform the shapefiles.<BR>
<BR>
<BR>
I am not completely sure what you are asking in question #1, but a<BR>
MapServer WMS service based on a PostGIS layer shouldn't look any<BR>
different to GeoMoose than one based on shapefiles.<BR>
<BR>
-----Original Message-----<BR>
From: mapserver-users-bounces@lists.osgeo.org<BR>
[<A HREF="mailto:mapserver-users-bounces@lists.osgeo.org">mailto:mapserver-users-bounces@lists.osgeo.org</A>] On Behalf Of Nelson<BR>
Soto<BR>
Sent: Tuesday, May 13, 2008 7:56 AM<BR>
To: mapserver-users@lists.osgeo.org<BR>
Subject: [mapserver-users] PostGIS or Mysql and GeoMoose.<BR>
<BR>
<BR>
For performance reasons, I may need to convert SHP's into a spatial<BR>
database. I loosely understand the concept of how this work but my<BR>
questions to anyone reading are:<BR>
<BR>
1. Has anyone looked into specifically doing the above with their<BR>
working demo of GeoMoose using SHP files previously? I would hate to<BR>
scrap the work I've done utilizing the excellent usability of GeoMoose<BR>
in favor of utilizing a spatial database.<BR>
<BR>
2. If users are typically accessing data but not writing it, will I<BR>
realize a performance upgrade *typically*.<BR>
<BR>
3. Is there any functionality I can expect to break and essentially head<BR>
into an 'uncharted territory' if I did indeed attempt this. Can I<BR>
basically expect to find in my way a high level of techincal issues (I'm<BR>
very technical, but I am trying to find an efficient approach)<BR>
<BR>
Also, here is a description of what I had attempted to do...<BR>
<BR>
We have an OS X server which contains 2 dual core Xeons processors and<BR>
4GB of ram. We are mainly a Windows house and had aquired the hardware<BR>
in an anquisition and would like to utilize this hardware as best as<BR>
possible. This is one of our more ambitious products we one day would<BR>
like to offer our clients (we currently offer an Access product that is<BR>
quite dated.).<BR>
<BR>
Originally, I had suggested perhaps getting Parellels VM software and<BR>
just bringing a copy of Windows Server 2003 to the table, but my<BR>
performance almost seems better on my test machine... I'm not sure if<BR>
that will apply to concurrent users which is certainly an aspect of the<BR>
issue at hand, but the VM software only detects 1 core... not good. We<BR>
are not looking at VMWare or anything where the license will exceed or<BR>
approach the cost of a new server otherwise we will do so.<BR>
<BR>
If I host PostgreSQL or MySQL on the server and away from the server<BR>
that would host GeoMoose (a new server) I would hopefully like to<BR>
utilize the Mac in this way seeing as how I can not get the performance<BR>
I would like out of virtualized hosting.<BR>
<BR>
Yes, I realize I can just set up Mapserver for OS X but, in my oppinion,<BR>
it is a very laborious task and I am foreseeing I will be the one having<BR>
to maintain this server and while I myself and relatively comfortable<BR>
maintaining OS X and its Unix skeleton, I want to minimize the work I<BR>
need to do to this server...<BR>
<BR>
I will post this on GeoMoose mailing list as well as Mapserver as I<BR>
realize there is some overlap in exactly what area's this does cover.<BR>
While the context of this topic does cover my use of GeoMoose with<BR>
Mapserver, I'm thinking there are users on both of these lists that have<BR>
experience with the advantages vs disadvantages of Spatial DB Data vs<BR>
SHP on disk.<BR>
<BR>
At any rate, any input is appreciated.<BR>
<BR>
Thanks,<BR>
Nelson<BR>
_______________________________________________<BR>
mapserver-users mailing list<BR>
mapserver-users@lists.osgeo.org<BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/mapserver-users">http://lists.osgeo.org/mailman/listinfo/mapserver-users</A><BR>
_______________________________________________<BR>
mapserver-users mailing list<BR>
mapserver-users@lists.osgeo.org<BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/mapserver-users">http://lists.osgeo.org/mailman/listinfo/mapserver-users</A><BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>