This page is part of the MapGuide Future section, where ideas are proposed and refined before being turned into RFCs (or discarded). Visit the Future page to view more!

Most of this is based on observation and light analysis of the MapGuide source code. Some of this stuff may sound nonsensical because I have totally misunderstood the purpose of a given component/library. MapGuide Developers, feel free to correct any mistakes

Overview

MapGuide contains all of the features of a great desktop mapping component: Data access, rudimentary GIS, stylization and more.

Although the current build is tightly bound to a server service, it would be useful to create a build profile (free of any server dependencies) that provided a desktop developer to quickly add spatial visualisation and interactivity to their application.

SDK purpose

The purpose of the MapGuide desktop SDK, would be to allow the application developer to perform common MapGuide tasks outside of the realm of web applications, without the dependency of the MapGuide Server and Web tiers. A desktop-based MapGuide API would also be ​the ideal client utility layer for FDO.

SDK contents

A MapGuide desktop SDK would most likely have these projects (in source form or dll/headers/libs) as the "core"

• Common/CoordinateSystem
• Common/Geometry
• Common/Foundation
• Common/MdfModel
• Common/MdfParser
• Common/MapGuideCommon
• Common/PlatformBase
• Common/Renderers
• Common/Schema
• Common/Stylization
• Server/src/Gws/GwsCommon
• Server/src/Gws/GwsQueryEngine
• Server/src/Gws/GwsResource
• Any 3rd party libs these projects depend on

If we were to take the Geospatial Platform API in AutoCAD Map as an example, the desktop-specific components would be:

• A desktop-based implementation of PlatformBase, that would mainly be providing desktop implementations of:
  • MgFeatureService
  • MgResourceService
  • MgMapBase
  • MgSelectionBase
  • other abstract classes(?)

The MgResourceService implementation would have to use an alternative to Berkeley DBXML due to licensing issues. Possible alternatives for a MgResourceService backing store include:

• ​Sedna XML DB
• SQLite ?
• Native filesystem with some sort of MgResourceIdentifier <-> file path addressing scheme.

In terms of handling the managed/unmanaged resources divide, a desktop-based MapGuide could use a Sedna/directory combination or just simply a series of directories (one for each alias + one special directory for managed resources)

Implementing MgFeatureService should be easy, since most methods in MgFeatureService are 1:1 with the FDO API

This may sound like a case of NIH, seeing as MapGuideCommmon already provides an implementation of PlatformBase. The problem is that MapGuideCommon's implementation of PlatformBase has all the server/ACE/dbxml dependencies that we don't want or need in a desktop context (obviously because the server is using this library). The reason MapGuideCommon would exist in the desktop SDK is so that a desktop-based MapGuide can interop with a MapGuide Server, as we are currently doing in the Web Tier.

MapGuide Server Integration

A desktop-based MapGuide should have some form of integration/compatibility with MapGuide Server.

API

On the API side of things, this implementation would have the same API parity as the AutoCAD Map Geospatial Platform API and have the same limitations:

• No MgRenderingService
• No MgMappingService
• No MgDrawingService
• No MgKmlService
• No MapGuide Server specific APIs (eg. MgSite, MgSiteConnection)

Resource Compatibility

A desktop-based implementation should be able to support all of the required MapGuide resource types, with the exception of:

• WebLayout
• ApplicationDefinition
• PrintLayout (since we're not implementing MgMappingService)
• DrawingSource (if we want no DWF dependency)
• SymbolLibrary (if we want no DWF dependency)

Namely, because these are web-specific resources that have cannot really be translated into a desktop context. Every other resource type should be consumable in a desktop context.

Data

Since a desktop implementation would have to implement MgResourceService::ApplyPackage(), MGP packages would be easily reusable in a desktop context, only web-specific resources would be ignored/discarded when loaded into a desktop context.

Ideally there should be some way to consume MapGuide server layers directly, and the easiest solution for that would be to implement a ​MapGuide FDO Provider. That way MapGuide can function like a WFS/WMS server, but you get all the nice FDO metadata that may have been lost by going through WFS/WMS. A MapGuide FDO provider would allow for dead simple replication of MapGuide Feature Sources.

A desktop application framework

At this point we would have a MapGuide API that is totally functional in a desktop context, free of any server dependencies and/or idioms. The only thing missing is the application side of things. If we want users to be able to build desktop MapGuide applications with very little programming knowledge, then we would need a desktop-based equivalent to the WebLayout/ApplicationDefinition.

This framework would have a library of pre-defined widgets, so that the out-of-the-box functionality matches your basic AJAX/Fusion viewer:

• Legend (Layer Control)
• Map Selector
• Map Canvas
• Mini-Map
• Menu
• Toolbar
• Button
• Split Button (Flyout)
• Context Menu
• Task Pane (Or some generic content container?)
• Attribute Viewer
• Scale Bar
• Generic Search/Query (Maybe something like AutoCAD Map's Data Grid instead?)
• Generic Theme
• Generic Redline
• Generic Buffer
• Generic Measure
• Help
• About
• Print
• Others?

And of course if you need custom functionality, just roll your own widgets. Now it would be impractical from a resource perspective to write all this stuff from the ground up, we should be basing this framework on a pre-existing library.

That is where ​Qt comes in. Qt is a very popular framework for cross platform applications and has just about every possible feature that we would ever need to use. As of v4.5 (current version is 4.6) it is licensed under the LGPL, thus there is no licensing issues at all. Qt provides all the necessary building blocks for a widget-driven desktop application framework.

Having to code C++ for custom widgets/functionality isn't fun, but Qt makes interop with other higher-level languages very easy. Thus API bindings in other languages is an easy task.