[mapguide-internals] The selection of a feature appears to be inefficient

[Gabriele Monfardini]

Dear all,

I'm using mapguideOS 2.1, Basic Layout and PHP.

in my application I need to have a function which selects a feature in the map.
This is useful, for instance, when the user does a Ctrl+click on a
feature when another one is selected.
In my opinion it may be misleading to display the info of the clicked
feature but in the map is still selected another one.

Thus I managed to clear the selection and select the clicked feature.

Looking at the Viewer API I would like to have found a function
SetSelection(layer, sqlWhereClause) but the only suitable function
appears to be SetSelectionXML(xmlSet) to be called on the mapFrame
http://mapguide.osgeo.org/files/mapguide/docs/2.0/viewerapi.html#mapframe_setselectionxml

This function needs a well-defined XML, complaint with
FeatureSet-1.0.0.xsd, with the feature id encoded in BASE64, thus
difficult to obtained without going through the API

I made an AJAX call from a javascript function (let's call it
'mySelectionJavascriptFunction()') to a PHP script (let's call it
'mySelection.php') that constructs the XML starting from the layer and
the id of the feature.
This involves some calls to the Web API, that end with a MgSelection::ToXml();

The obtained XML is then passed to SetSelectionXML and indeed all works.

However, having a look to the webserver log and mapguide-apache log
the procedure seems to need 3 calls to PHP pages.
This are my findings:

The SetSelectionXML(xmlSet) needs for its processing two distinct xmls:

1. the input parameter 'xmlSet' that is used to produce the blue selection image
2. another xml, 'xmlOut', needed to obtain and inject the selected
feature properties into the Property Panel of the Viewer.

The 'xmlOut' is produced calling the function SetSelection() that
makes a request to a PHP page, setselection.php, that parses the xml
to extract the layer and the feature id and produces 'xmlOut' (on a
side note, it uses MgFeatureInformation->ToXml() that seems not
present in the API documentation...).

This 'xmlOut' is then passed to "ProcessFeatureInfo(xmlOut, false, 2)"
that discards it (!!) and calls RequestSelectedFeatureProperties()
which in turn call yet another PHP page, getselectedfeature.php that
responds with a JSON object (let's call it 'resp') with the very same
properties of the feature, that is then passed into a bunch of other
javascript functions, starting with ProcessSelectedFeatureSet(resp),
that are not interesting in this analysis.

Javascript computation is not a problem, but too many round-trip calls
to PHP pages on the server affects server performance.
Moreover, each PHP script makes a lot of routine calls to the API,
basically to verify user credential, create the services, open the
runtime map, iterating through the layers and so on.

In summary, each selection involves 3 calls to PHP pages (the symbol
=> means a call to a PHP page, the symbol ----> means its return
value, followed by an example instance):

1. mySelectionJavascriptFunction() => mySelection.php ----> xmlSet

<?xml version="1.0" encoding="UTF-8"?>
<FeatureSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="FeatureSet-1.0.0.xsd">
    <Layer id="6e0efb1c-d07d-11df-8000-001276243361">
        <Class id="OGRSchema:edifici~edifici_tematizzati_view">
            <ID>OAAAAA==</ID>
        </Class>
    </Layer>
</FeatureSet>

2. SetSelectionXML(xmlSet) => setselection.php ----> 'xmlOut'

<?xml version="1.0" encoding="UTF-8"?>
<FeatureInformation>
    <FeatureSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="FeatureSet-1.0.0.xsd">
        <Layer id="6e0efb1c-d07d-11df-8000-001276243361">
            <Class id="OGRSchema:edifici~edifici_tematizzati_view">
                <ID>OAAAAA==</ID>
            </Class>
        </Layer>
    </FeatureSet>
   <Tooltip>tooltip</Tooltip>
   <Hyperlink>URL</Hyperlink>
   <Property name="id" value="56" />
   <Property name="anotherProperty" value="42" />
</FeatureInformation>

This 'xmlOut' contains all the properties of the feature and it is
strangely discarded by ProcessFeatureInfo(xmlOut, false, 2)

3. ProcessFeatureInfo(xmlOut, false, 2) calls
RequestSelectedFeatureProperties() => getselectedfeature.php ---->
resp

{"edifici" : [{"values" : [{"name" : "id", "value" : "48" },{"name" :
"anotherProperty", "value" : "42" }], "zoom" : { "x": 1673376.1291158,
"y": 4736296.95092 } }]}

Apart from the zoom (that IMHO is not used in further processing) this
is simply the json version of the properties in xmlOut


In my opinion (and my implementation) the whole selection can be
obtained with only a call to a PHP script, that produces both 'xmlSet'
and 'xmlOut', and its jsonified version 'resp' that can be passed to
the ProcessSelectedFeatureSet(resp).
Much less calls to the API and only one PHP pages called.
I decided to re-enter mapguide code with the call to
ProcessSelectedFeatureSet(resp) since no any other calls to PHP pages
are made in subsequent computation and I don't want to duplicate
mapguide code that probably will evolve in next releases.

Am I wrong in my conclusions?
Should I open a ticket in order to streamline the selection?

Regards,

Gabriele Monfardini