Monday, 26 August 2013

MapGuide 2.6 feature showcase: QUERYMAPFEATURES improved

For this post, I will be talking about another useful enhancement to the mapagent: An improved QUERYMAPFEATURES operation.

To understand the motivation for this. Open up your Firebug or Chrome DevTools on the AJAX/Fusion viewer of your current stable/production installation of MapGuide/AIMS and make a selection on the map.

You probably see something like this for the AJAX viewer

And for Fusion, you probably see something even noisier

From a performance standpoint, firing off 3 and 5 requests respectively for a single selection smells of inefficiency. What is the actual root cause of such inefficiency? The answer is simply: QUERYMAPFEATURES

In its current form, the QUERYMAPFEATURES operation in the mapagent is simply inadequate for fulfilling the needs of our current suite of client-side map viewers.
  1. Select and give me back attributes of all the selected features? Not possible. That's why the AJAX viewer before RFC 71 could only show a number of selected features. Though RFC 71 introduced a getselectedfeatures.[php/jsp/aspx] to fetch this attribute information, it still needed an additional request to do it. It's also why Fusion has to make several extra requests through various PHP backend scripts to get this information.
  2. When you make a selection, the viewer then has to make an additional GETDYNAMICMAPOVERLAYIMAGE to retrieve the selection image.
  3. QUERYMAPFEATURES is also used for tooltip requests, but the response carries extra unnecessary baggage like selected feature attributes.
For 2.6, we introduce a more powerful and flexible QUERYMAPFEATURES operation that can handle all of the above scenarios, being an efficient one-stop shop for all viewer selection/tooltip needs. We can achieve this by using the same technique as the new CREATERUNTIMEMAP operation: The client application requests the pieces of information they are interested in, and the QUERYMAPFEATURES operation returns the appropriate information in the response.
  1. The application can fire off a QUERYMAPFEATURES request to include attributes of all selected features. This avoids the need for a request to getselectedfeatures.[php/jsp/aspx] in the AJAX Viewer (in fact, the introduction of this operation has rendered getselectedfeatures.[php/jsp/aspx] obsolete). In Fusion this avoids the need to call into the various PHP scripts for the same information
  2. The application can also request an inline base64 selection image as part of the QUERYMAPFEATURES response. Through the magic of data URIs, the AJAX viewer can directly set the selection image without needing to fire off an additional GETDYNAMICOVERLAYIMAGE request. However, for Fusion it still needs to do this because the OpenLayers.Layer.MapGuide instance doesn't support plugging in base64 selection images directly yet.
  3. The application can fire off a QUERYMAPFEATURES request and only ask for tooltip/hyperlink information.
All the above cases demonstrate the capabilities of the new QUERYMAPFEATURES operation:
  • Attributes of all selected features are included (if requested). AJAX viewer no longer needs getselectedfeatures.[php/jsp/aspx]. Fusion no longer needs to call the various PHP scripts to assemble this information.
  • Inline selection images are included (if requested) as data URIs. No need for an additional GETDYNAMICMAPOVERLAYIMAGE request for the selection image.
  • You only get what you ask for. No extra unnecessary information traveling down the wire.
So how does the request chatter look like with this new operation in place?

Here's the new request chain for the AJAX viewer. A single request to the enhanced QUERYMAPFEATURES operation asking for the kitchen sink. No need for an additional GETDYNAMICOVERLAYIMAGE because QUERYMAPFEATURES includes an inline base64 image that the viewer can insert as a data URI. No need to call getselectedfeatures.[php/jsp/aspx] because the response contains the attributes of all selected features.

Here's the new request chain for the Fusion viewer. I suspect the SaveSelection.php request is somewhat redundant here because QUERYMAPFEATURES already supports modifying the selection set.

Combine this enhanced QUERYMAPFEATURES with the new CREATERUNTIMEMAP/DESCRIBERUNTIMEMAP that I already talked about and you have a powerful set of out-of-the-box functionality for building your own map viewer without needing any .net/PHP/Java assistance.

For more information about this new feature, you can have a look at the RFC that introduced it: RFC 126.


Unknown said...

I've been trying to use QUERYMAPFEATURES in our own OpenLayers viewer but all I'm getting is this:

Any ideas how that might be? Where should I be looking?

Unknown said...

I'm trying to use QUERYMAPFEATURES in our own OpenLayers viewer, but I can't seem to find any data. All I'm getting is this:

Do you know where I could be going wrong? My request string is like this: