Changes between Version 3 and Version 4 of FDORfc57

Timestamp:

Mar 23, 2011, 7:04:22 PM (13 years ago)

Author:

gregboone

Comment:

--

FDORfc57

@@ -43 +43 @@
 Basically, the goal is that users must be able to not only connect to WMS services and add features to maps from those services; they should also be able to click on map features to get more information.[[BR]]
 As to the 1.1.0 version, the standard employs the x = pixel_column and y = pixel_row to replace I = pixel_column and J = pixel_row.[[BR]]
+
 More details regarding the WMS !GetFeatureInfo request can be found in the WMS standards http://www.opengeospatial.org/standards/wms.
 
 == Proposed Solution ==
 
-The shortest WMS !GetFeatureInfo implementation path would involve implementing !GetFeatureInfo request within the current FDO WMS provider. The design solution would provide a custom command to users to retrieve the feature information: FdoWmsCommandType_GetFeatureInfo.[[BR]]
+The shortest WMS !GetFeatureInfo implementation path would involve implementing !GetFeatureInfo request within the current FDO WMS provider. The design solution would provide a custom command to users to retrieve the feature information: !FdoWmsCommandType_GetFeatureInfo.[[BR]]
 
 '''•    Input of the !GetFeatureInfo request'''[[BR]]
+
 From the required parameters table above, we can see !GetFeatureInfo requires almost all the parameters required by !GetMap request and plus more, the custom command would also require the same input for Select command and extra parameters (i, j coordinate in pixels of feature in Map CS). [[BR]]
 
 '''•    Output of the !GetFeatureInfo request'''[[BR]]
+
 The format of responded message from the !GetFeatureInfo request is defined by the WMS server. For example:[[BR]]
+
   <Format>text/plain</Format> [[BR]]
   <Format>text/html</Format>[[BR]]
-Currently, the WMS implementation specification doesn’t define a standard format for it. So, the solution is to return a FdoString* type pointer by this command. If user set the FEATURE_COUNT greater than 1, the information for multiple candidate features will be returned. However, we don’t parse the returned information since no standard regarding the format and client should take the responsibility to parse it.  For example the following text is returned from one server to response the !GetFeatureInfo request.[[BR]]
-Layer 'IBA'[[BR]]
+
+Currently, the WMS implementation specification doesn’t define a standard format for it. So, the solution is to return a !FdoString* type pointer by this command. If user set the FEATURE_COUNT greater than 1, the information for multiple candidate features will be returned. However, we don’t parse the returned information since no standard regarding the format and client should take the responsibility to parse it.  For example the following text is returned from one server to response the !GetFeatureInfo request.[[BR]]
+
+     Layer 'IBA'[[BR]]
      Feature 6:[[BR]]
      SITEID = 'NU009'[[BR]]
      NAME = 'Queen Maud Lowlands' [[BR]]
      LINK = 'http://www.bsc-eoc.org/iba/site.jsp?siteID=NU009' [[BR]]
-
 
      Feature 66:[[BR]]
@@ -198 +203 @@
 == Implications ==
 
-•       A new command FdoWmsCommandType_GetFeatureInfo is added for WMS provider.
+•       A new command !FdoWmsCommandType_GetFeatureInfo is added for WMS provider.
 
 == Test Plan ==