Changes between Version 2 and Version 3 of FDORfc57


Ignore:
Timestamp:
Mar 23, 2011, 6:59:21 PM (13 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc57

    v2 v3  
    1 = FDO RFC 57 - Implement the GetFeatureInfo command for WMS provider  =
     1= FDO RFC 57 - Implement the !GetFeatureInfo command for WMS provider  =
    22
    33This page contains a request for comments document (RFC) for the FDO Open Source project. 
    … …  
    2222== Overview ==
    2323
    24 The RFC is to implement the GetFeatureInfo command for WMS provider.
     24The RFC is to implement the !GetFeatureInfo command for WMS provider.
    2525
    2626== Motivation ==
    2727
    28 GetFeatureInfo is an optional operation of WMS server. It is only supported for those Layers for which the attribute queryable="1" (true) has been defined or inherited.
    29 The GetFeatureInfo operation is designed to provide clients of a WMS with more information about features in the pictures of maps that were returned by Get Map requests. The canonical use case for GetFeatureInfo is that a user sees the response of a Map request and chooses a point on that map for which to obtain more information.
    30 Here is the table of the parameters of a GetFeatureInfo Request based on the 1.3.0 version:
     28!GetFeatureInfo is an optional operation of WMS server. It is only supported for those Layers for which the attribute queryable="1" (true) has been defined or inherited. The !GetFeatureInfo operation is designed to provide clients of a WMS with more information about features in the pictures of maps that were returned by Get Map requests. The canonical use case for !GetFeatureInfo is that a user sees the response of a Map request and chooses a point on that map for which to obtain more information.
     29
     30Here is the table of the parameters of a !GetFeatureInfo Request based on the 1.3.0 version:
     31
    3132||'''Request parameter'''       ||'''Mandatory/optional'''      ||'''Description'''||
    3233||VERSION=1.3.0         ||M     ||Request version||
    33 ||REQUEST=GetFeatureInfo        ||M     ||Request name||
     34||REQUEST=!GetFeatureInfo       ||M     ||Request name||
    3435||map request part||    M       ||Partial copy of the Map request parameters that generated the map for which information is desired.||
    3536||QUERY_LAYERS=layer_list ||    M       ||Comma-separated list of one or more layers to be queried||
    … …  
    3940||J=pixel_row   ||M     ||j coordinate in pixels of feature in Map CS||
    4041||EXCEPTIONS=exception_format   ||O     ||The format in which exceptions are to be reported by the WMS (default= XML)||
     42
    4143Basically, 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]]
    4244As 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]]
    43 More details regarding the WMS GetFeatureInfo request can be found in the WMS standards http://www.opengeospatial.org/standards/wms.
     45More details regarding the WMS !GetFeatureInfo request can be found in the WMS standards http://www.opengeospatial.org/standards/wms.
    4446
    4547== Proposed Solution ==
    4648
    47 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]]
    48 
    49 '''•    Input of the GetFeatureInfo request'''[[BR]]
    50 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]]
    51 
    52 '''•    Output of the GetFeatureInfo request'''[[BR]]
    53 The format of responded message from the GetFeatureInfo request is defined by the WMS server. For example:[[BR]]
     49The 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]]
     50
     51'''•    Input of the !GetFeatureInfo request'''[[BR]]
     52From 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]]
     53
     54'''•    Output of the !GetFeatureInfo request'''[[BR]]
     55The format of responded message from the !GetFeatureInfo request is defined by the WMS server. For example:[[BR]]
    5456  <Format>text/plain</Format> [[BR]]
    5557  <Format>text/html</Format>[[BR]]
    56 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]]
     58Currently, 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]]
    5759Layer 'IBA'[[BR]]
    5860     Feature 6:[[BR]]
    … …  
    6769     LINK = 'http://www.bsc-eoc.org/iba/site.jsp?siteID=NU089' [[BR]]
    6870
    69 However, the following XML formatted message will return if issue the command to a MapGuide server. [[BR]]
     71However, the following XML formatted message will return if issue the command to a !MapGuide server. [[BR]]
     72
     73{{{
    7074<?xml version=”1.0”, encoding=”UTF-18”?> [[BR]]
    7175   < FeatureInfoCollection>[[BR]]
    … …  
    7781     </FeatureInfo> [[BR]]
    7882   </FeatureInfoCollection> [[BR]]
     83}}}
     84
    7985Note: we can parse the response value and return a class if WMS spec defines a standard format in the future.
    8086
    81 '''•    GetFeatureInfo custom command interface'''[[BR]]
     87'''•    !GetFeatureInfo custom command interface'''[[BR]]
    8288
    8389{{{
    … …  
    94100    /// Execute the FdoWmsIGetFeatureInfo command and returns a
    95101    /// FdoString* pointer, which points to the feature information returned
    96           /// by the WMS server.
     102    /// by the WMS server.
    97103    ///
    98104    /// \return
    … …  
    126132    /// \brief
    127133    /// Set the position (X, Y) which indicates a point of interest on the map that was
    128     /// produced by the embedded GetMap request.The point (X, Y) is a
     134    /// produced by the embedded !GetMap request.The point (X, Y) is a
    129135    /// point in the (i, j) space defined by the Map CS.
    130136    /// This function is mandatory; if not specified,
    … …  
    137143    /// Return nothing
    138144    ///
    139    FDO_API virtual void SetPosition(FdoIDirectPosition* pos) = 0;
     145    FDO_API virtual void SetPosition(FdoIDirectPosition* pos) = 0;
    140146
    141147    /// \brief
    142148    /// Get the position (X, Y) which indicates a point of interest on the map that was
    143     /// produced by the embedded GetMap request. The point (X, Y) is a
     149    /// produced by the embedded !GetMap request. The point (X, Y) is a
    144150    /// point in the (i, j) space defined by the Map CS.
    145151    ///
    … …  
    169175};
    170176}}}
    171 In this class, both methods GetFeatureClassNames and SetFeatureClassNames are used to get/set the feature class collection which would be mapped to WMS layers in order to query the relevant feature information. [[BR]]
     177
     178In this class, both methods !GetFeatureClassNames and !SetFeatureClassNames are used to get/set the feature class collection which would be mapped to WMS layers in order to query the relevant feature information. [[BR]]
    172179
    173180'''•    Example''' [[BR]]
    174 The GetFeatureInfo custom command will be used like below:
     181
     182The !GetFeatureInfo custom command will be used like below:
    175183
    176184{{{
    177 FdoPtr<FdoWmsIGetFeatureInfo> cmdGFI = static_cast<FdoWmsIGetFeatureInfo*> (connection->CreateCommand(FdoWmsCommandType_GetFeatureInfo));
     185FdoPtr<FdoWmsIGetFeatureInfo> cmdGFI = static_cast<FdoWmsIGetFeatureInfo*> (connection->CreateCommand(FdoWmsCommandType_!GetFeatureInfo));
    178186FdoPtr<FdoIdentifier> id = FdoIdentifier::Create(L”Park”);
    179187cmdGFI->SetFeatureClassNames(id);
    … …  
    183191FdoStringP featureInfo = cmdGFI->Execute ();
    184192}}}
    185 Since there are lots of same parameters required as GetMap request, the Execute function of this custom command will be similar with the select command. The difference is to pass the extra i, j values and fire the GetFeatureInfo request to WMS server. What’s more, share the same codes between select command and GetFeatureInfo custom command should be considered seriously.[[BR]]
    186 
    187 Similar to the GetMap request, the parameters regarding the GetMap parts should be obtained from the override configuration. If it’s not customized, the default parameters will be gotten from capabilities documents (returned from GetCapabilities).  One note is that the command should generally be called after the GetMap request; otherwise, the returned result is probably unexpected if the parameters are wrongly specified.
     193
     194Since there are lots of same parameters required as !GetMap request, the Execute function of this custom command will be similar with the select command. The difference is to pass the extra i, j values and fire the !GetFeatureInfo request to WMS server. What’s more, share the same codes between select command and !GetFeatureInfo custom command should be considered seriously.[[BR]]
     195
     196Similar to the !GetMap request, the parameters regarding the !GetMap parts should be obtained from the override configuration. If it’s not customized, the default parameters will be gotten from capabilities documents (returned from !GetCapabilities).  One note is that the command should generally be called after the !GetMap request; otherwise, the returned result is probably unexpected if the parameters are wrongly specified.
    188197
    189198== Implications ==