Project

General

Profile

« Previous | Next » 

Revision 3118

Added by perry almost 18 years ago

Initial architecture for dynamically generating SLD/OGC:Filter documents to control which docids get shown on the map. The sldfactory servlet is in place to handle this but is not fully functional since there is currently no way to quickly and dynamically generate a list of allowable docids with a level of performance acceptable for real-time web mapping.

View differences:

spatial_option.html
264 264
   <p style="margin-bottom:12pt"> Filter which spatial cache features are displayed by access contraints, skin constraints and the current non-spatial query set. This would involve intercepting incoming WMS requests and appending a styled layer descriptor (SLD) with an OGC filter to prevent/allow certain docids. </p>
265 265

  
266 266
   <h5>SLD factory</h5>
267
   <p style="margin-bottom:12pt">Closely related to the WMS bypass implemetation, the SLD factory would be in charge of constructing the filter based on on the contraints mentioned above. Because it would have to generate this list of docids on every wms request, performance is a big concern. Likely we'll need to cache docid lists as session variables.</p>
267
   <p style="margin-bottom:12pt">Closely related to the WMS bypass implemetation, the SLD factory would be in charge of constructing the filter based on on the contraints mentioned above. In other words, it would construct a document specifying which docids were to appear in the map. Because it would have to generate this list of docids on every wms request, performance is a big concern. Likely we'll need to cache docid lists as session variables.</p>
268 268

  
269
  <p> There is currently a stub implementation of the SLD Factory servlet in <em>src/edu/ucsb/nceas/metacat/spatial/SldFactory.java</em>. It is functional except that it doesn't generate a dynamic list of allowable docids.  Assuming we can modify the SldFactory servlet to quickly generate a list of allowable docids based on stored session variables, applying this SLD to a WMS request is fairly easy and simply requires appending the URL of the sldfactory as an "SLD" parameter to the WMS GetMap request: </p>
270

  
271
   <pre> http://indus/knb/wms?REQUEST=GetMap&SERVICE=WMS....&SLD=http://indus.msi.ucsb.edu/knb/sldfactory?originalSld=data_points_style.sld</pre>
272

  
273
<p> where data_points_style.sld is the original style document existing in <em>{context}/data/styles/</em>. The sldfactory servlet will construct a list of allowable docids, append those to the original sld as an ogc filter, an return a (modified) SLD document. There are two possibilities for implementing this:</p>
274

  
275
   <ol>
276
   <li>
277
     Mapbuilder (the WMS client in charge of constructing WMS request) can be told to append this SLD parameter through the use of the WMC config document. This would work for the skins but, alone, would not ensure that every WMS request were filtered since other clients could simply ommit the SLD parameter.
278
   </li>
279
   <li> 
280
     An alternative, one that would ensure that EVERY wms request was filtered, would be to handle it all server side with a WMS bypass.
281
   </li>
282
   </ol>
283
   
284
   
285

  
269 286
   <h5>Map configuration interface </h5>
270 287
   <p style="margin-bottom:12pt">Geoserver currently offers a nice web-based configuration but it is lacking a few key features and may be difficult for a novice GIS user. We may want to reinvent a custom geoserver configuration interface to</p>
271 288
   <ul>

Also available in: Unified diff