[mapguide-internals] A better QUERYMAPFEATURES (Re: The selection of a feature appears to be inefficient)

[Jackie Ng]

I want to necro this discussion as this is something we should seriously
address post-2.4.

So what is the root problem for such excessive round-tripping? The answer is
simply that QUERYMAPFEATURES does not fulfill the requirements that our
current lineup of client-side viewers are demanding, so we have to make
additional requests to other APIs or web extensions glue to work-around the
shortcomings of this API. Some examples:

 1) Select and give me back attributes of all features? Sorry,
QUERYMAPFEATURES can only return attributes for one. That's why the AJAX
viewer has to then make an additional call to
getselectedfeatures.[php/jsp/aspx] and why Fusion has to make at least 4
extra requests (!!!) through various PHP glue (!!!!!) to get the required
attribute information. QUERYMAPFEATURES should return all the attributes 

[Benefit: no additional requests for extra attribute data]

 2) QUERYMAPFEATURES also modifies the server-side selection, so it requires
a follow-up GETDYNAMICMAPOVERLAYIMAGE request to update the selection image.
If we can utilise data URIs to return the actual selection image back inline
(as base64 encoded content) as part of the response, this eliminates the
extra request. Sure, not all browsers support data URIs (you know which
one), so we can workaround that by letting the client specify if they want
the inline selection image (browsers that support data URIs will say "yes"
and those that can't will say "no").

[Benefit: no additional requests for browsers that support data URIs. Those
that don't will fall back to existing behaviour.]

 3) QUERYMAPFEATURES for tooltip requests doesn't need attribute
information, so don't include this information.

[Benefit: Less data through the wire]

So how can have have a better QUERYMAPFEATURES that can satisify all of the
above requirements? Let the client specify what bits of information they
want. So:

 1) and 2) wants attribute information, with an inline selection image if
possible
 3) Only wants tooltip and hyperlink information

We could bitmask this request information like so:

 Attributes = 1
 InlineSelection = 2
 Tooltip = 4
 Hyperlink = 8

The MapGuide Server would then use this mask to figure out what pieces of
information to return back to the client.

This would obviously need an XML schema update and a change to
MgFeatureInformation (or maybe a new class?), which I've yet to fully figure
out, but I want to just get the discussion rolling.

Thoughts? Would this solve the issues of excessive roundtripping and
selection inefficiency?

- Jackie

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/The-selection-of-a-feature-appears-to-be-inefficient-tp4210532p4988955.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.