Saturday 18 December 2010

By your powers combined...

Since everyone at my company knows about it already. It's safe to tell the rest of the world.

I am leaving AEC Systems at the end of next week (and this year) after a 4.5 year run. There's been many ups and downs, but ultimately I am grateful to AEC Systems for giving me the opportunity to learn and ultimately allowing me to ascend in my career and knowledge (professionally and personally) to where it is today.

A New Year is the perfect time for a new beginning.

So starting early January next year, I will be joining forces with fellow MapGuide guru and PSC member, Zac Spitzer and his talented crew at Ennoble Consultancy for some fun and interesting times in the MapGuide/FDO/Geospatial realm.

Stay tuned. Exciting times are ahead for sure.

Friday 10 December 2010

My MapGuide Wishlist

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

My FDO wishlist

Since it's that time of the year, and Autodesk loves them customer surveys and wishlists...

1. A way to use the FDO API in languages other than C++/.net in a multi-platform manner

FDO is a multi-platform API. I like .net, it is portable too assuming you target a safe and mature subset of the .net framework libraries (which I already do).

Unfortunately, the .net wrapper for FDO is not multi-platform and if you're not careful the .net Garbage Collector who is normally your friend, becomes your worst enemy as it prematurely cleans up your wrapped FDO objects from under your feet and you're greeted with the all-too-common AccessViolationException being thrown at you.

SWIG can wrap C++ code in a multi-platform manner. GDAL does this. MapGuide already does this, why not FDO as well? There's already a Python wrapper generated by SWIG (albeit Windows-only last I checked), so it's not exactly impossible!

I don't mind having to use C++ if I have no other choice. But higher level languages does yield greater productivity. It's how I got FDO Toolbox to become so feature-packed in such a short period of time. The fact our Linux users cannot use FDO Toolbox because of lack of flexible development options (that is not C++) is disappointing.

2. Champion SQLite as the goto flat-file format for FDO

Now I don't mean product support. Because it's already getting love from the latest releases of AutoCAD Map3D and MapGuide Studio. I mean having SQLite become the de-facto flat file format that showcases all of the features supported by FDO.

What do I mean exactly? I mean features you normally find in a RDBMS provider like:
  • Association Properties
  • Object Properties
  • Schema Element Attributes
  • etc
3. A FDO provider for MapGuide

Sure, there's no write capability built into the mapagent, but having a read-only FDO provider for MapGuide would greatly improve interoperability between FDO client applications and MapGuide. It would basically be like WFS, but without the impedance mismatch and loss of metadata. As MapGuide is built on FDO, it knows everything about FDO and the capabilities can be parameteric with respect to the underlying Feature Source.

You could possibly even have raster support by just extending existing Rendering Service APIs with required raster functionality (querying, sub-sampling, etc) and exposing this through the mapagent.

4. Consistent Schema Naming Conventions

This is already a well-documented problem, but I'll extend it with a possible solution.

For those providers that hard-code a schema name (because they don't support the concept of a logical schema and just need a name), how about instead we define the default schema name in an external configuration file and these providers can read off of this file instead? This way, not only is it unified, but unified to your preferences.

Having to write implementation-specific code in an abstraction layer like FDO defeats the whole concept!

5. Parametric Capabilities

Capability APIs break down on providers like ODBC and OGR due to their "one size fits all" nature of these providers. It would be nice if ODBC and OGR actually have capability discovery, for these capabilities to be translated to corresponding FDO capabilities, so we don't get a whole bunch of -1 values for FDO capabilities like maximum length of a property.

6. Android/iPhone support

Hey this is a wishlist after all! Smartphones are all the rage these days. No need to port everything. Just the base SDF/SHP/SQLite providers would suffice.