I made one for FDO, so here's one for MapGuide...
1. A desktop-based variant of the Geospatial Platform API
Despite web applications being touted as the best thing since sliced bread. I believe there is still a sizable market and demand for a Desktop-based MapGuide product without the full-blown feature set of
AutoCAD Map3D.
Autodesk used to have a product like this. It was called Envision (before that, it was called OnSite Desktop) and it worked with MapGuide 6.x (or possibly older) SDF files. There hasn't been anything similar from Autodesk since.
That's not to say we can't do it ourselves.
It is conceptually possible to take MapGuide in directions that do not involve the Server and Web Tier, but the amount of implementation (or re-implementation) work required is just too much. There are huge swaths of useful utility code that is currently stuck in the Server and WebTier code-bases that should really be inside some sort of reusable utility library.
Not to mention that there are several Server-only modules that have no real server dependencies. There is utility outside of a MapGuide Server / Web Tier in having standalone MgDrawingService, MgRenderingService, MgKmlService and GwsQueryEngine modules. For most convenience, it would be nice to have them merged into the base platform libraries (MgPlatformBase.dll).
Such a current development requires working with the full MapGuide source tree, not exactly the smallest thing out there to have to download/checkout.
That way, the only real implementation effort would be:
- MgFeatureService (can simply be a straight wrapper around FDO).
- MgResourceService (can simply be a pre-defined directory with a SQLite-backed database to store metadata and resource dependencies).
- MgMapBase (can simply reuse MapGuide implementation)
- MgLayerBase (can simply reuse MapGuide implementation)
- MgSelectionBase (can simply reuse MapGuide implementation)
2. A HTML5/Flash/Silverlight vector viewer with offline support
A rich HTML5/Flash/Silverlight viewer has the primary benefits.
- Reduced server load and better performance. The viewer would only need to perform queries for features. Everything else is done client-side.
- Richer user experience due to everything being done client-side
- Client side features are actual geometries, as we a not requesting a rendered image everytime we pan/zoom/refresh/etc. So we can do things like client-side selection, object snapping, etc.
I emphasize offline support (which HTML5 and Silverlight can do, not sure about Flash) because if the previous item is too much effort, an offline-capable web map viewer is the next best thing.
The old MapGuide 6.5 ActiveX viewer could do this through "fat" MWF files (filled with static layers). I just wish there was something similar with current MapGuide technology.
3. A scalable Fusion Legend widget
Fusion has had many teething problems since its introduction several releases ago, but nowadays it is mostly functional and usable, except for the Legend widget. Given a moderately large map, the legend widget just breaks down.
It also doesn't help that fusion is the default previewing mechanism in
MapGuide Studio so you can expect previews on large themes to timeout consistently (that's what you get for embedding Internet Explorer!). I've had to advise clients from using Fusion simply because I knew it couldn't handle the large maps that they have, which is a shame because it perfectly satisfied all their other requirements!
4. A way to preserve tile sets.
Ever change something innocuous like the title of your Map Definition and MapGuide suddenly takes off and nukes your tile set from orbit? Yes, it's very annoying because it isn't exactly fast to produce these tile sets!
I think the best solution is to have a tile set defined as a separate resource, any Layer Definitions (and by extension, Feature Sources) that are used as part of this tile set resource are locked from editing. My current thinking is that a tile set definition (if you will) would have the following information:
- Path to where the generated tiles will be stored. Can be %MG_DATA_FILE_PATH% for managed, or an external path or alias. Come to think of it, %MG_DATA_FILE_PATH% is probably a bad idea as packaging will take an eternity.
- The Layer Definitions participating in this tile set.
- The Coordinate System (to re-project any non-matching layers)
- The scales applicable for this tile set.
MapGuide already knows the dependency chain of any resource, so it can stop any edits made to dependent layers and feature sources of a given tile set. The tiled layer component of the Map Definition would be deprecated in favour of references to tile sets (or probably be a new resource type so as not to break the additive qualities of previous schema revisions)
This way once a tile set is defined, it is not possible to trash the generated tiles unless you say so as layer and feature source changes/updates/deletions will be denied by MapGuide due to its knowledge of dependent resources.
5. Feature Write capabilities for the mapagent
Failing that, merge
GeoREST into MapGuide, you'll get pretty much the same result.
6. A DWG FDO provider
I understood in the past why it was not possible. But the release of
AutoCAD for Mac has proven that Autodesk finally have multi-platform DWG access technology. So get to it! It will definitely add extra value to a licence of
MapGuide Enterprise
Posts
