Martin, I disagree with your statement that MapGuide will have far
more development and support going forward.
Caveat Emptor: The arguments that follow are purely my opinion and are
not based in empirical evidence, mostly just my observations having
worked with both platforms. Take them with a grain of salt :)
MapServer has a large and active developer community spread across
individuals and companies that actively improve the software on a
daily basis. The MapServer mailing list is large and very helpful,
and there is a wealth of user-contributed documentation that grows
with every release. MapServer's code base is (in comparison) small,
light weight, understandable. It has a relatively low cost of entry
for new developers wanting to do stuff.
MapGuide, on the other hand, is still largely dependent on a single
(but very large) benefactor and has yet to attract additional (core)
developers outside of the core team from ADSK. It does have a growing
community support infrastructure through this mailing list, which is
probably the first step towards growing the development community.
The code base is quite large, complex, and not readily understandable
by a developer wanting to get started with it. None of this points to
'far more' development or support going forward.
I would also argue that MapServer, when properly configured, is faster
than MapGuide - at rendering maps. If you need to generate map images
for the web, MapServer is generally going to be faster than MapGuide.
There are some fundamental differences, though, that need to be
understood when making this comparison.
1) Enterprise scalability. It has been said that MapGuide is intended
for Enterprise deployment (it supports multiple 'web tier'
installations accessing multiple site/support servers potentially
through a corporate firewall and distributed across multiple
machines. ) with the implication that MapServer is not Enterprise
ready. In fact, this is not true and it is equally as possible to set
up a similar architecture using MapServer - the main difference is
that MapGuide has an installer that sets this up whereas the MapServer
solution would have to be designed by a knowledgeable group. When
requesting a map image, then, MapGuide has a minimum of three
processes that need to be involved - the web server, the 'web tier',
and the 'server tier'. MapServer only has two, the web server and the
MapServer process.
2) Statefulness. MapGuide is stateful in that you have to establish a
session with the server and refer to that session in every request to
the server. MapServer is stateless and has no inherent concept of
sessions. For applications that require statefulness, MapGuide is
typically simpler to use whereas MapServer requires an external
framework to make it stateful and that framework adds overhead that
makes the performance of MapGuide perhaps better than MapServer. For
applications that don't require statefulness (such as serving WMS or
Tile requests), MapServer is simply faster because it doesn't have the
overhead of statefulness built into its architecture (granted that for
WMS and Tiles - MGOS 2.0 only - you can request images directly
without needing a session, so that is less of a difference).
3) Optimization. Optimizing for MapGuide and MapServer are very
different tasks. For both, you really need to understand the
expensive parts of drawing a map - is it accessing the data, filtering
it, classifying it, or rendering it - and how to minimize bottlenecks
in each of the parts. I would argue that it is more feasible to tune
MapServer's performance than MapGuide's. This is, in part, because
you have more options with MapServer - different ways of accomplishing
the same task. MapGuide is probably more tuned to start with but my
experience is that beyond optimizing your data, there isn't much more
you can do to tune MapGuide's performance by playing with cartographic
options.
For data access, MapGuide has FDO, OGR and GDAL support. MapServer
supports roughly the same set of data sources, except it doesn't
support FDO and hence can't access SDF files. DWF support is not part
of FDO, and its actually more of an *output* format than an *input*
format. It also requires an activex control to render it, which makes
it more-or-less useless to me and many others that need applications
that support multiple web browsers and platforms. An FDO connection
type for MapServer has been discussed and seems likely to happen at
some point, although no specific plans have been made - so MapServer
will gain access to SDF at that point.
Regarding speed of data access, MapServer is generally considered
fastest when used with properly prepared shapefiles, although PostGIS
is arguably on par with it. MapGuide is generally considered fastest
when used with SDF. I have had very poor success with SDE access
(MapServer is about 3-6 times faster at drawing from an SDE data
source) in MapGuide. I have no knowledge of Oracle Spatial in either
platform, although MapGuide is supposed to be quite good with Oracle.
Cartographically, the two are quite similar. MapServer has quite a
few more options for styling data at this time, but MapGuide has some
really nice styling features that MapServer doesn't have. Again, it
depends on what your critical factors are. I would say that in
general it is possible to achieve the same effect with both servers
unless you have somewhat specialized needs. MapGuide is arguably
poorer with raster data sources. MapServer can do things like raster
classification and raster querying, whereas MapGuide can just render
them as-is (I think I saw hill shading show up in MGOS 2.0, which
MapServer doesn't support). On the other hand, since MGOS 1.2 there
are some extremely complex cartographic things you can do especially
with line work that are not possible at this time in MapServer.
Coming back to Tim's original question, though, I think that perceived
performance in this case is likely 'application' performance. As
noted above under statefulness, application performance doesn't
compare directly because you have to use another framework with
MapServer. In this case, Chameleon was built on pre-ajax web
technologies and is particularly poor compared to MapGuide, Fusion,
MapFish, MapBuilder, etc which have all kept up with, or been written
for, the times. Chameleon is quite horrible in fact - it does all its
calculations on the server, creating high load and reducing
responsiveness of the server under multiple simultaneous user load,
and it reloads the page on every request which multiplies the
problem. 'Modern' frameworks put a lot of the processing on the
client side (in javascript), which reduces server load dramatically
and allows a server to 'scale up' to meet higher load, minimizes the
amount of information that needs to be transfered back and forth, and
uses ajax techniques to keep the application responsive even while it
is waiting for server-side processing to happen.
So at the end of the day, my feeling is that the problem is with the
framework that Tim is using around MapServer, not with MapServer
itself. The real question is which framework should Tim move to. And
on that particular subject, I don't have enough experience with
platforms other than Fusion to comment on effectively.
Cheers
Paul
On 8-Feb-08, at 4:28 PM, Martin Morrison wrote:
I don't have statistics, but years ago I played around with MapServer,
it was all right, but was not polished or speedy. I find that
MapGuide
can be both. MapGuide also will allow for more types of data SDF, DWF
to name two.
I think MapGuide will have far more development and support going
forward.
Just my 2 cents.
Martin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nolte,
Tim
Sent: Friday, February 08, 2008 4:24 PM
To: MapGuide Users Mail List
Subject: RE: [mapguide-users] Differences between UMN MapServer &
MapGuide...
I guess what I am looking for is what are the strengths and weaknesses
of both. Basically our MapServer currently serves both Shapefiles (39
layers) & Oracle Spatial (11 layers) data. My biggest concern is
user-perceived performance. Our current server config is a 3.06GHz
Opteron w/ 8GB of RAM. I've tried to tune our data as best I can
however
I'm still concerned about the end-user perceived performance. As most
people are, I'm up against people expecting our MapServer to perform
with the same speed as Google Maps. I'm also looking for something
with
a very visually polished development framework. I know that looks
aren't
everything but it does offer some credibility to the information being
presented. Thanks for any input anyone has.
- Tim
----
Timothy J Nolte - [EMAIL PROTECTED]
Associate Network Planning Engineer
iPCS Wireless, Inc.
4717 Broadmoor Ave, Suite G
Kentwood, MI 49512
Office: 616-656-5163
PCS: 616-706-2438
Fax: 616-554-6484
Web: www.ipcswirelessinc.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Birch
Sent: Friday, February 08, 2008 4:05 PM
To: MapGuide Users Mail List
Subject: RE: [mapguide-users] Differences between UMN MapServer &
MapGuide...
I guess I should ask what your reasons for considering moving away
from
MapServer are. What needs do you have that it is not meeting?
They both certainly have their strengths and weaknesses, but I don't
know if any recent in-depth analysis of the differences.
Jason
_______________________________________________
mapguide-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
_______________________________________________
mapguide-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
_______________________________________________
mapguide-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
