Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I'm wary of starting a debate based on opinion, so I lifted my title from this question which seems to be doing fine. I'm also worried about offending MapGuide enthusiasts so please understand I am simply trying to avoid unwise strategic decisions.

When I try to install, use, develop with, ask questions about, or otherwise entertain MapGuide OS I get the feeling that starting a new project with MapGuide is too risky:

  • API documentation has not been updated for years and developers are asked to use 2.0 docs for the 2.2 and 2.4 product
  • It took several months from the time 2.2.0 was released for http://mapguide.osgeo.org/ to recognise that 2.1.0 was not the latest stable release, suggesting that no one is actively maintaining the site
  • Install documentation is spread wide and thin. I recently spent the best part of a week trying to install on 64-bit linux for use with Oracle and ultimately had to give up (then installed GeoServer in less than one hour)
  • Forum threads regularly end unanswered or stumble along with hopeful suggestions only to end with an unanswered question from the OP
  • I personally have never managed to get a .NET map viewer up and running due to compile errors that others have reported but had no luck fixing
  • It seems like a lot of the effort that goes into MapGuide comes from a very small number of people (especially Jackie Ng) which doesn't bode well should they ever get too busy or lose interest in the project.

Someone recently asked a similar question on the MapGuide forum but it took a decidedly ambiguous tone and ended with no clear answer.

I appreciate that a lot of work has gone into the project, and also that it provides functionality I can't find elsewhere (this is a big part of the problem I have), as it can provide a complete viewer experience in short order. However in addition to the list above I have other issues:

  • Dependency on stateful sessions and associated load balancing considerations
  • Requirement for a configuration tool or web service to create opaque configuration files / databases that can't be edited or viewed easily
  • PHP web viewer's need for a specific version of PHP which is unlikely to be compatible / ideal for other PHP applications on a shared server
  • Distinction between IE and other browsers in the viewers due to ActiveX

Yes, I know that this is an Open Source project and so if I think it needs improving I should get involved, but honestly I would much rather donate my time to other projects like GeoServer or OpenLayers as these products have both made my life much easier and have well defined roadmaps.

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Allow me to address your points individually:

API documentation has not been updated for years and developers are asked to use 2.0 docs for the 2.2 and 2.4 product

Nearly all of MapGuide's API changes to the present day have been additive in nature (a new class here, a new method there). Only in very exceptional circumstances are classes or methods actually modified or removed. So to this end, even though you've been asked to use the 2.0 docs, they are still mostly applicable, with new classes and methods since then detailed in the respective MapGuide RFC that introduced them.

Still that does not excuse the fact that the "published" online API documentation is still at 2.0, and once again it's due to a lack of an active caretaker to maintain the mapguide.osgeo.org site and keep it up to date.

It took several months from the time 2.2.0 was released for http://mapguide.osgeo.org/ to recognise that 2.1.0 was not the latest stable release, suggesting that no one is actively maintaining the site

As explained above, lack of a mapguide.osgeo.org caretaker

Install documentation is spread wide and thin. I recently spent the best part of a week trying to install on 64-bit linux for use with Oracle and ultimately had to give up (then installed GeoServer in less than one hour)

Could you not say the same thing about any piece of software written in C++? We gain performance and responsiveness at the expense of ease of installation and configuration due to potential dll-hell trying to communicate with various 3rd party external libraries. We try to make installation and configuration as simple as we can but some external components will simply refuse to cooperate with MapGuide unless a very specific set of parameters are met.

Then again, Oracle isn't exactly renowned for ease of configuration is it? :)

Forum threads regularly end unanswered or stumble along with hopeful suggestions only to end with an unanswered question from the OP

We try to provide answers where we can, but I find unanswered threads usually are of the following:

  1. Lack of specific details. A one sentence question saying something "doesn't work" doesn't really help us in trying to assist you solving your problem. There are many other factors we normally need to know about like:

    • System Specs
    • MapGuide Install Configuration
    • Steps to reproduce
    • etc, etc.

    These are the stock pieces of information that any software support personnel would require in order to provide help.

  2. Coding/Programming problems that can be easily answered by a Google search or StackOverflow (or any related StackExchange site). Or posts containing pages and pages of unformatted source code, ending with "how can I fix this? Plz help me, it's urgent". Or people who follow up your answers with "It doesn't work" because they probably copy/pasted your sample code verbatim without fully understanding the context of the answers given. These type of posts reek of pure laziness on the part of the OP.

  3. English not being the OP's primary language. Well, we can't do much about this one.

  4. A super-specialized use case that nobody else has ever thought of. We can't do much about these questions either, because we never tried using MapGuide in this particular way that has been described.

The mailing list is kind of like this site (or any other StackExchange site), minus the meta-commentary and up/down voting of questions and answers. We can't exactly downvote silly or often-repeated questions on the mailing list. So rather than flaming such people (I don't do that, trying to be a model OSS citizen here), I just ignore them.

I personally have never managed to get a .NET map viewer up and running due to compile errors that others have reported but had no luck fixing

Again, the problem is due to MapGuide's C++ nature. The .net map viewer isn't truly .net code, it is .net code that wraps a whole set of MapGuide native libraries in C++. Same goes for Java and PHP viewer. Most .net viewer problems are a combination of:

  • Incorrect .net Framework version
  • Incorrect "bitness" of the IIS application pool with respect to the bitness of the MapGuide installation.
  • Missing the required MapGuide native libraries that the .net assemblies call into

The regular perils of trying to auto-configure IIS from a windows installer.

It seems like a lot of the effort that goes into MapGuide comes from a very small number of people (especially Jackie Ng) which doesn't bode well should they ever get too busy or lose interest in the project.

You could cite this one problem as the reason why the project as a whole seems to be stagnating, why the site isn't updated, why documentation isn't updated, etc, etc.

Yes, MapGuide Open Source does suffer from a low bus factor. At the end of the day, I'm just a passionate user and developer, and that is all an Open Source project really needs: More guys/gals like me (not exactly like me, but power users/developers submitting the occasional patch to fix or enhance something, writing the occasional blog post to spread their knowledge, writing the occasional piece of sample code to show how to do X/Y/Z, updating the occasional piece of documentation, etc, etc).

Financial funding helps too, but it seems Open Source software has this "free lunch" mentality that is hard to shake off.

I'm personally interested in how the other OSGeo projects (esp. MapServer and GeoServer) fare against MapGuide. These projects don't have backing from a major software vendor like Autodesk, so how to these projects get by? Do these projects face similar problems? Are their user communities the same? How do these projects stay alive?

As for your specific issues:

Dependency on stateful sessions and associated load balancing considerations

This is a consequence of the server-heavy architecture of MapGuide. The original design was probably along the lines of "let the server do all the hard work" which is probably the right choice at the time given the requirement of a client-side map viewer that doesn't require plugins and the state of web browsers at that time (2004-2006)

Requirement for a configuration tool or web service to create opaque configuration files / databases that can't be edited or viewed easily

The configuration files are plain XML files. They are just stored in an ACID-compliant container (a berkeley DBXML database if you're wondering), so that such files aren't easily corrupted by concurrent multi-user access.

PHP web viewer's need for a specific version of PHP which is unlikely to be compatible / ideal for other PHP applications on a shared server

This is mostly a windows problem again due to MapGuide being written in C++ and needing to talk to assorted libraries of various languages. This is doubly compounded by the fact that Microsoft Visual C++ is the dominant compiler on Windows, and if you know C++ you cannot just mix and match various binaries built from different C++ compilers. So we have to build and bundle everything ourselves. Needing a specific version of PHP is a consequence of this.

On Linux, this isn't a problem but the MapGuide build system inherits all of the ugly kludges for windows, so we just kind of roll with it for Linux as well.

Distinction between IE and other browsers in the viewers due to ActiveX

This is not true. MapGuide Open Source is architecturally different from MapGuide 6.5. There has never been a plugin-based viewer and for the sake of the modern web, I hope there never will be.

So after all that, I guess I didn't really answer your original question. Well let's ask the most important question here.

What are the requirements for your project?

  • Simply putting up an interactive map on the internet/intranet with tools for basic querying and spatial analysis? MapGuide excels at this. Tools like MapGuide Maestro (which I am the author of), makes this process even simpler.

  • Integration with other software/systems? If it's consuming existing external data stores, MapGuide also does this very well through FDO. If it's consuming external web services or providing web services for consumption by other systems, it falls a bit short here. If were talking OGC standards, only WFS and WMS are supported for service consumption and exposure.

  • Rich and complex spatial analysis like routing, network tracing, kriging, etc? You're now venturing into pure customization territory or possibly looking at Autodesk's commerical offerings as MapGuide Open Source doesn't support this out of the box.

Basically, as your [system integration or spatial analysis] requirements grows, the greater need there is for customization and programming. Which brings up my next point.

People often call Linux the "hacker's OS", I'd like to call MapGuide the "hacker's GIS". If you know how to code competently, questions that you may have (as long as they don't fall into the 4 aforementioned categories, because we get enough of them on the mailing list) do generally get answered or give you enough clues to find your solution.

If you're more GIS user than a programmer, then as the South Park ski instructor would say, "you're gonna have a bad time". Because if MapGuide doesn't do something you need out of the box, you'll have to write some code.

Just my 2c.

Disclaimer - I'm a software developer first, a GIS person second, sales/marketing way down the bottom of the list. I have not used MapServer, GeoServer or any other OSGeo alternatives to MapGuide. Skewed opinions may be the result

share|improve this answer
    
Thanks for the detailed and thorough response. One thing that jumps out - "If you're more GIS user than a programmer... you're gonna have a bad time". To me MapGuide is supposed to target the user, not the programmer. That's why it provides pre-cooked viewers and a GUI configuration tool - it's supposed to be useful with very little input, not a "hacker's GIS". Projects like OpenLayers and GeoServer are exclusively for developers as they require development to be useful. As a contractor my time is expensive, and MG needs too much of it. Most importantly: would you use it for a new project? –  tomfumb Aug 15 '12 at 17:32
    
Also please note that my misunderstanding of the IE / ActiveX distinction is a result of reading the documentation (Getting Started with Map Guide) on mapguide.osgeo.org/2.0/documentation.html –  tomfumb Aug 15 '12 at 17:52
    
Cleaned up my actual answer a bit, rather than just saying "if you can't code, MapGuide probably isn't for you" –  jumpinjackie Aug 16 '12 at 2:04
    
Just coming back to this, thanks again for the input. I think the Linux "hacker's OS" analogy is a little off the mark. Linux (as represented by its more popular distributions) is a very mature and stable system that only requires getting your hands dirty if you choose to - due to an unusual requirement, configuration need, or software dependency. To reduce this question to 'can you code competently' is overly simplistic. As a professional developer of 6 years with a post-grad GIS education I like to think I'm capable. For me this is more a question of time vs results, and time is expensive. –  tomfumb Jul 16 '13 at 20:25

I'd like to add my 2 cents in here. I've been using MapGuide in both the enterprise and opensource form for a few years now, I can say that the out of the box software will allow you to display spatial data from many sources over the web and give some simple feature information dialogs for the users, layer styling is very managable through the maestro tool or simply modify the libraries XML directly.

My MapGuide project started out in .Net, I've since moved to PHP and Fusion with the latest release, finding the fusion widget fairly good way of extending the mapguide interface.

I have no official programming training I've learnt by annoying the hell outta everyone and anyone that would listen :) (Jackie has answered many a question with a simple one liner)

I often refer to the mapguide api distributed with the installer and haven't had any dramas with it. I have managed to accomplish everything my user base has requested with mapguide.

At some stage I would like to contribute my little changes back to the community so they can be disected / improved / laughed at :)

I moved away from a proprietry WEB GIS authoring tool because the API was poorly maintained, it had hard to understand logic and required specialised input for any customization, mapguide "to me" is quiet the opposite easy to modify extremely open and well documeneted api.

I have a very cross platform system (mapguide works wonders here):

  • Bentley Map (XFM DGN) - Data we produce in hosue
  • SQL Spatial - Data linked to other systems
  • ECW - Aerial Imagery (satellite and vertical)
  • CSV - Small datasets maintained internally
  • SHP - Data sourced externally
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.