Maestro 3.0: A comprehensive walkthrough (part 1)

As I promised, this is the first part of many posts on showing the many new features of Maestro 3.0.

The Main Application Window

So after you login in, here's what you get:

Look familiar? Yes, the overall UI design is modelled on FDO Toolbox. In fact, Maestro uses a more-refined version of the same extensible foundation and design concepts used by FDO Toolbox. If something works for you, why change it? :)

Originally, I also wanted to use the same DockPanel library as I did in FDO Toolbox, but having found out that the library is riddled with P/Invokes into the Win32 API, it was instantly unsuitable for my needs because getting this thing to work in Mono is a fundamental requirement.

So after failing to find a portable alternative, and the vanilla winforms TabControl being woefully inadequate (no close buttons on tabs???? c'mon!) I had no choice but to roll my own. The end result is quite acceptable:

And, the whole reason for doing this, here's how it looks on Linux (I'm using a VM of the OSGeo Live DVD, which comes with Mono 2.4)

Aside from some visual bugs due to Mono's implementation of WinForms, the two are essentially visually and functionally identical. Mission accomplished!

Now what's this thing at the bottom?

One of my design goals of FDO Toolbox and Maestro 3.0 is for the application to be as transparent as possible, you should be able to have a good guess at what is happening behind the scenes as you do anything. Thus if something goes wrong, you should have a good log of what had happened.

The Outbound Requests view lets you see all the outbound http requests that Maestro is making to the mapagent endpoint. It's a very useful diagnostic tool. The Messages tab displays any other diagnostic or debugging messages that Maestro may show.

The Site Explorer.

In the previous version of Maestro, the Site Explorer was based on the standard TreeView component. Though it is mostly functional for our needs it had one very annoying limitation: You could only select one item at a time.

For this version of Maestro, the Site Explorer is now based on the TreeViewAdv control. The TreeViewAdv gives us the the multi-selection that we desire and works in Mono (there's Win32 P/Invokes, but they are only used for profiling performance and not in the main code). So win win!

So with multi-selection now available to us, it means we can have different context menus for different selection scenarios. Here's the current context menu for a single selected resource

If you're wondering what Repoint this resource does, it's a feature suggested by Jason Birch which lets you specify all resources referencing the current resource, to reference another resource of your choice instead.

If we selected multiple resources, we get something different.

If you're wondering what Migrate Resources does, it's another feature suggested by Jason which lets you move or copy the selected resources to another MapGuide Server. This function currently doesn't handle resource version compatibility when moving/copying to an older MapGuide Server. It will naively assume the target MapGuide Server supports the versions of the resources you are moving/copying over.

As you can see, this is an untapped design space that has been made open as a result of being able to select multiple items at once. Expect more time-saving commands in future releases as a result.

While we're on the time-saving front, the Site Explorer also supports drag and drop of many different items. Here's some of the things you can drag and drop in Maestro 3.0:

• Drag and drop a SDF file to create a SDF feature source at the location you dropped the file. The file is embedded into the feature source.
• Drag and drop a SHP file to create a SHP feature source at the location you dropped the file. Any related files will also be brought in. The files are embedded into the feature source.
• Drag and drop a SQLite file to create a SQLite feature source at the location you dropped the file. The file is embedded into the feature source.
• Drag and drop a MGP file to load the package.
• Drag and drop a XML file to create a resource (based on the content of the XML file) at the location you dropped the file.

Applying the Unix Philosophy

The Unix Philosophy can be summarised as: Write programs that do one thing, and do it well.

Though Maestro is primarily an authoring application for MapGuide, it's core can be re-used and re-purposed for many specialized needs due to the vast array of functionality and services exposed by the MapGuide Server. You have already seen this in action in the previous version with the MgCooker tile generator. We have taken this approach further in this version with a whole bunch of little specialized tools:

The Feature Source Preview Tool

Use this to do FDO Toolbox style data queries on any MapGuide Feature Source

The MapGuide Server Monitor

Use this to observe the current Server statistics as reported by the MapGuide Server

The Feature Source Cache Viewer

Use this to view the state of the Feature Source cache, and find out what connections are currently in use.

All these tools (including MgCooker) are available under the Tools application menu.

That's all for part 1. Stay tuned for part 2!

Announcing: MapGuide Maestro 3.0 beta 1

After 10 months of on again, off again development, the next version of MapGuide Maestro is finally here in beta form, if you're brave enough to try it out.

The amount of changes since version 2.1 is way too much for one blog post to contain.

Apart from a completely new user interface, Here's a high-level summary of changes:

• Test Release 1: Changes
• Test Release 2: Changes
• Test Release 3: Changes
• Test Release 4: Changes
• Beta 1: Changes

I'll be posting a series of posts to provide a "visual walkthrough" of all the new features, bells and whistles, because nothing is better than showing new features through screenshots (lots of screenshots!)

You can download the beta (zip or installer) from the Maestro homepage. The beta will not clash with previous releases of Maestro. You can install the beta side-by-side with your existing installation.

Announcing: FDO Toolbox 1.0 beta 4

Here's a new release for the new year.

Some of the highlights include:

• Experimental support for variables in Sequential Processes. I'll elaborate on this in a future post.
• Experimental support for flow control in Sequential Processes. I'll elaborate on this in a future post.
• Express connect support for King Oracle provider
• Support for XML configured connections in Bulk Copy tasks (no UI support yet)
• Geometry properties in Object Explorer now show spatial context and geometry types
• Connections in Object Explorer now also show if an XML configuration has been applied

And some fixes too:

• Fix not being able to edit spatial contexts in Data Store Editor
• More intelligent handling of spatial contexts when creating geometry properties on-the-fly with Bulk Copy
• Saved connections also persist any configuration information
• Restore Sequential Process tasks on startup
• Fix faulty logic when copying spatial contexts to a connection that supports multiple spatial contexts
• Fix exception when copying to SQL Server and new Class Definitions were created.

Come and get it

Report Issues / Enhancements

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.

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.

Announcing: FDO Toolbox 1.0 beta 3

Here it is! The 3rd beta of FDO Toolbox 1.0

Some of the highlights include:

• A new type of automated task: Sequential Process
• FDO 3.6.0 (build F037). Like I said previously, the old PostGIS provider is no longer bundled.

Along with some fixes:

• FDO Data Stores containing Object and Association properties can now be exported
• Improved Object and Association property support in the Data Store Editor
• Insert/Update/Preview support for Object and Association properties. Many thanks to Crispin for providing this patch
• Geodetic polygons with bad orientation are fixed when bulk copying to SQL Server 2008

Download

Report Issues/Enhancements