Changes between Version 8 and Version 9 of MapGuideRfc126

Timestamp:

May 6, 2013, 3:49:25 AM (11 years ago)

Author:

jng

Comment:

--

MapGuideRfc126

@@ -290 +290 @@
 }}}
 
-Inline selection images are rendered out as inline base64 string, inside the <Content> element of the <InlineSelectionImage> element, avoiding an additional GETDYNAMICMAPOVERLAYIMAGE request. This exploits the new Data URI feature supported by most modern browsers, the AJAX and Fusion viewers can do the capability checks client-side to determine whether to request an inline selection. Attributes of all features are grouped by their respective layer name. 
+Inline selection images are rendered out as inline base64 string, inside the <Content> element of the <InlineSelectionImage> element, avoiding an additional GETDYNAMICMAPOVERLAYIMAGE request. This exploits the new Data URI feature supported by most modern browsers, the AJAX and Fusion viewers can do the capability checks client-side to determine whether to request an inline selection. Attributes of all features are grouped by their respective layer name.
 
 The inline image does not have the mime-type prepended to the string. It is included as a separate <MimeType> element of the <InlineSelectionImage> element. Browsers that can support data URIs can assemble the final data URI from these components. Non-browser clients should be able to have the necessary means to process the base64 content based on the given <MimeType> value.
@@ -300 +300 @@
 The AJAX viewer will need some slight modifications to deal with the new QUERYMAPFEATURES response as the structure differs from what is returned by getselectedfeatures.[php/jsp/aspx], but the content is the same. Selected features can be grouped by layer name and each individual selected feature has a bounding box for the "Zoom to current feature" function to work. If data URIs are supported, the viewer needs to simply check the content of the {{{InlineSelectionImage}}} property in the response. If it is not empty, it can be assigned straight into the {{{<img>}}} element that holds the selection image, otherwise we proceeed as normal and send off a GETDYNAMICMAPOVERLAYIMAGE request for that image. With the implementation of this RFC, getselectedfeatures.[php/jsp/ajax] will no longer be required and can be removed.
 
-Because we have the bounding box of individual features client-side, we gain an additional benefit by eliminating a GETFEATURESETENVELOPE request for the "Zoom to Selection" command, as we can instead compute the aggregate bounding box based on the bounding boxes of our selected features and use that instead for calculating the desired zoom level/location.
+Because we have the bounding box of individual features client-side, we gain an additional benefit by eliminating a GETFEATURESETENVELOPE request for the "Zoom to Selection" command, as we can instead compute the aggregate bounding box based on the bounding boxes of our selected features and use that instead for calculating the desired zoom level/location. In fact, the AJAX viewer will get new APIs to access this new information:
+
+{{{
+
+function GetSelectedBounds()
+    Returns the bounding box of the selected features. Returns null if no features are selected. The box is a Bounds object:
+
+    Bounds {
+      minx; /* The min x coordinate of this bounding box */
+      miny; /* The min y coordinate of this bounding box */
+      maxx; /* The max x coordinate of this bounding box */
+      maxy; /* The max y coordinate of this bounding box */
+    }
+
+function GetSelectedFeatures()
+    Returns the selection set including attributes of selected features. The selection set is structured like so:
+
+    {
+        layerName1 : [
+        { //feature 1 in layerName1
+            values: [
+                { name: "attribute1", value: "value1" },
+                { name: "attribute2", value: "value2" },
+                { name: "attribute3", value: "value3" },
+                ...
+                { name: "attributeN", value: "valueN" }
+            ]
+            zoom: { minx: <feature1_bbox_minx>, miny: <feature1_bbox_miny>, maxx: <feature1_bbox_maxx>, maxy: <feature1_bbox_maxy> }
+        },
+        { //feature 2 in layerName1
+            values: [
+                { name: "attribute1", value: "value1" },
+                { name: "attribute2", value: "value2" },
+                { name: "attribute3", value: "value3" },
+                ...
+                { name: "attributeN", value: "valueN" }
+            ]
+            zoom: { minx: <feature2_bbox_minx>, miny: <feature2_bbox_miny>, maxx: <feature2_bbox_maxx>, maxy: <feature2_bbox_maxy> }
+        },
+        ...,
+        { //feature N in layerName1
+            values: [
+                { name: "attribute1", value: "value1" },
+                { name: "attribute2", value: "value2" },
+                { name: "attribute3", value: "value3" },
+                ...
+                { name: "attributeN", value: "valueN" }
+            ]
+            zoom: { minx: <featureN_bbox_minx>, miny: <featureN_bbox_miny>, maxx: <featureN_bbox_maxx>, maxy: <featureN_bbox_maxy> }
+        }
+        ], layerName2 : [
+            ...
+        ], 
+        ..., 
+        layerNameN : [
+            ...
+        ]
+    }
+
+
+
+}}}
 
 For Fusion, it gets a bit more complicated as it makes various calls to assorted PHP scripts (SaveSelection.php, GetSelectionProperties.php, etc). This asynchronous call chain of PHP scripts needs to be refactored so that it only needs to send the new QUERYMAPFEATURES request and process its response as it does all the things that these PHP scripts were previously needed for. In addition, it's client-side selection structure is radically different from that of the AJAX viewer. Given the very early stage of this RFC, discussion with Fusion developers is needed to determine if the sample responses proposed here is enough to replicate the existing client-side selection model and this RFC will be updated accordingly based on developer feedback.