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

[Gabriele Monfardini]

Hi all,

I've opened a ticket regards the inefficiency of the selection of a feature.
http://trac.osgeo.org/mapguide/ticket/1464

I'm a little bit concerned about having no feedback on this, since
selecting an object is one of the very basic and most used tasks.
Moreover the inefficiency seems to have worsened from version 2.1 to 2.2.

Any feedback?

Gabriele Monfardini




On Wed, Oct 6, 2010 at 13:10, Gabriele Monfardini <gabrimonfa at gmail.com> wrote:
> 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
>