Opened 14 years ago
Closed 11 years ago
#1464 closed defect (fixed)
The selection of a feature appears to be inefficient (too many server calls)
Reported by: | gabrimonfa | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | AJAX Viewer | Version: | 2.2.0 |
Severity: | trivial | Keywords: | |
Cc: | External ID: |
Description
I'm using mapguideOS 2.2beta, Basic Layout and PHP.
in my application I need to have a function which selects a feature in the map.
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:
- the input parameter 'xmlSet' that is used to produce the blue selection image
- 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):
- 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>
- 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>
<Tooltip>tooltip</Tooltip> <Hyperlink>URL</Hyperlink> <Property name="id" value="56" /> <Property name="anotherProperty" value="42" />
This 'xmlOut' contains all the properties of the feature and it is strangely discarded by ProcessFeatureInfo(xmlOut, false, 2)
- 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
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.
Change History (3)
follow-up: 2 comment:1 by , 12 years ago
comment:2 by , 12 years ago
RFC 126 seems very reasonable to me and should solve my issues in a more principled way. Data URIs are also very welcome. Unfortunately I am not able to test sandbox branch due to lack of time.
comment:3 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed with the implementation of RFC 126
Please take a look at MapGuide RFC 126 - Viewer selection optimization, and have a play with the sandbox branches referenced within that RFC if you are able to.
This RFC should solve your issues, and it's done at the mapagent level, so no web extensions glue required.