Re-visiting the Maestro layer style editor

Consider the current layer style editor in Maestro

Now, despite being serviceable for our needs it does suffer from several shortcomings:

• A lot of controls are being created to produce this UI. This is really sluggish when you're editing a style with lots of rules and you need to scroll a lot. We also run the risk of running out of handles if we're editing a really big style.
• The style previews are Maestro-drawn approximations. Composite styles are blank because we simply have no idea how to draw them in pure .net. Using GETLEGENDIMAGE solves our style preview accuracy problems, but the way this UI has been set up makes it hard to use GETLEGENDIMAGE on say a 100 rule layer (arguments about why you have a layer with 100 theme rules aside) without clogging up your application.

The UI as whole looks like a data grid of sorts. Shouldn't this whole UI be more easier and streamlined if it was grid based?

Yes indeed, so that's what we've done. Meet the new grid-based style editor.

The benefits of the grid-based editor is that because we are using a DataGridView component, we have the ability to not only leverage data-binding against rule objects with very little code plumbing, but also to be able to determine what rules are actually in view on the grid.

As a result, we can issue GETLEGENDIMAGE-based previews only for what you currently see. These requests are also done asynchronously on a background thread, ensuring maximum application responsiveness while not making the MapGuide Server cry since we are only asking for previews for what we can currently see.

Clicking on the Filter cell brings up the Expression Editor. Clicking the LegendLabel cell lets you edit the cell contents. Clicking the Style cell brings up the matching point/line/area style editor and clicking the Label cell brings up the label style editor. Any edits you make are immediately visible on the grid when you close the editor dialog.

When you scroll through the grid, you can see rules that haven't had a preview generated for them yet.

To see the previews for these rules, you can click the Refresh Previews button to refresh the style previews for the rules currently in view.

So now that we have a means for having accurate style previews without obsessively hammering a MapGuide Server, it means that we can also show previews for composite styles. Something that was not possible with the old editor.

Clicking the Style cell for a composite rule in this case still brings up the mega-verbose Symbol Instances dialog for editing composite symbolizations, but at least there's no longer a need to delve into this particular dialog just to get a style preview for a composite rule, because like the other style types, previews for composite rules are also shown in the grid as well.

Moving to a grid-based UI opens up other avenues that were not possible before, like being able to filter the current list of rules by some criteria (handy if you want to focus on some specific rules in a layer with 50+ rules). Not that we have done this already, but these are things that a grid-based UI gives us the ability to explore.

Another improvement that's only available for this grid-based style editor is support for theming composite styles. There are some caveats with this support:

• The theming algorithm is very naive and basic due to the complexity of Advanced Stylization and the thousands of different possible permutations that a given composite rule could be in. However if you stick to a basic prototype of an un-styled point/line/area the theming algorithm should be able to pick up the relevant color property and apply the theme color ramp to it.
• On that subject, theming a composite style requires a rule to already exist in the style as a prototype. While this is optional for basic styles, this is required for composite styles.

Now that's not to say we have replaced the old style editor. A new feature like this needs some time to be blooded in as a proper replacement. The old editor is still available if you un-tick the new editor option we've added to the options dialog.

The next release of Maestro will use the grid-based editor by default.

Announcing: mapguide-rest 0.6

Here's the first release of mapguide-rest

And a general disclaimer: This is still work-in-progress code that's not ready for production use. However, that shouldn't stop you from downloading this release and having a play around :)

I have a bunch of mapguide-rest related posts in the draft queue, but it helps to have an accessible release as a point of reference for these posts rather than tell you to get the latest git clone of mapguide-rest.

One thing that stands out in this release since the initial announcement is the introduction of integrated REST API documentation.

What? REST API documentation? Aren't RESTful APIs self-describing, self-documenting and all this other stuff?

That may be true in an ideal sense, but pragmatism trumps idealism. mapguide-rest is the GET/POST/PUT/DELETE to a set of well-crafted URLs variety of REST API. In such cases, it definitely helps to know the definitive list of allowed URLs you can make requests to and the documented parameters that are allowed for each URLs.

So this is what we've provided for you. The documentation can be accessed at the following URL:

http://yourservername/mapguide/rest/doc/index.html

But this isn't a static document.

It's a fully interactive one!

The interactivity allows you to fully explore the REST API in a very intuitive fashion.

All this was made possible with the use of the Swagger documentation framework. The API reference is built on a modified version of Swagger UI. I've found Swagger to be a wonderful tool for generating REST API documentation. The initial set up takes some effort, but the pay-off of the final result is so worth it!

So now that we have a release on the board, stay tuned for more about the GeoREST-style data publishing framework.

Download

Generating themes by external lookup values

Ever generate an individual theme on a property and get frustrated at the labels that are generated because your property is basically a "foreign key", where the real descriptive labels come from the lookup table that the foreign key points to?

Sure you could set up a view (if your Feature Source is a relational database) to include the descriptive label properties or (gasp) make an Extended Feature Class that uses Feature Joins to pull in the description properties, but there's overhead involved when theming on strings as opposed to theming on numerical lookup ids.

Wouldn't it be nice if there's a way where we can theme based on description values from a lookup table but retain the ability to theme by the base numerical or string lookup id?

In the next release of MapGuide Maestro, we've solved this problem for you.

Meet the new Theme Generation dialog

The Data Setup portion of the dialog has been split into 2 sections:

• Theme based on values/ranges from this class: This is the existing theming option
• Theme based on values from an external class: This is the new theming option where you can source the theme rules from an external class definition (eg. A lookup table)

To illustrate this new feature, consider we're theming against the Parcels Feature Source from the Sheboygan Sample data set (as per the above screenshot). We'd pick the RTYPE property, which tells us that 8 theme rules will be created.

Now unfortunately, the RTYPE property only contains abbreviated values and the theme that gets generated doesn't produce very informative labels (as seen in the first screenshot).

Now suppose we had an external Feature Source or lookup table that has descriptive labels for these RTYPE values.

We can use the new theming option to generate theme rules using the main property as a frame of reference.

Firstly, you would specify the Feature Source containing your lookup table

Then specify the Feature Class that represents the lookup table

Then you specify the key and value properties that will determine the filters and labels that will be generated for your theme rules.

If you want to apply any filtering on the lookup table itself to reduce the number of rules that would be generated, you can specify the FDO filter in the Filter field.

Then click Update to get a feel for the number of rules that will be generated. The rules that will be generated follow this form:

• Filter: RTYPE = [Value of Default:ParcelType.Type]
• Label: [Value of Default:ParcelType.Description]

At this point, you can then tweak the color setup and other theme generation settings as before. Once you click OK you can see that the theme rules generated match the values from your lookup table.

As you can hopefully see, this feature should dramatically simplify theming of features from relational databases without requiring any table/view contortions to get the desirable theme rules.

Creative uses for Watermarks

I give you exhibit A: Injecting useful debugging information into a rendered map.