Changes between Version 5 and Version 6 of GeoServer_integrationActivities


Ignore:
Timestamp:
06/19/08 16:49:55 (17 years ago)
Author:
etj
Comment:

Obsoleted task table

Legend:

Unmodified
Added
Removed
Modified
  • GeoServer_integrationActivities

    v5 v6  
     1----
     2
     3'''THIS TABLE MAY BE OBSOLETE. '''
     4
     5Please read below.
     6
     7----
    18
    29== List of Activities for !GeoServer Integration ==
    310
    4 GN = !GeoNetwork team
    5 
     11GN = !GeoNetwork team [[BR]]
    612GS = !GeoServer team
    713
     
    3036||  ||  ||  ||
    3137|| GS || Communication layer to !GeoServer || Create a tiny communication layer to communicate with !GeoServer. This will be provided as a separate jar that will include a high level API to access GS's services. The API must include at least the operations needed for the integration (create service, remove service, ...). ||
     38
     39
     40----
     41Obsolete part ends here
     42----
     43
     44
     45Given the current GS implementation of layer publication, and the fact that many metadata required for publishing the layer are already included in the ISO standard, the use case may be different than the one described in the above table.
     46
     47 1. A user edits a metadata, uploading the file as it is needed. Metadata also contains informations about layer type and SRS.
     48 1. An item in the metadata list provided by the metadata search will have the button ''publish'' (or ''unpublish'') related to it, if the resource has a valid layer stored in GN, and the logged user has edit privileges on the metadata itself.
     49 1. When the ''publish'' button is pressed, GN will create the REST URLs needed by GS to publish the given layer. The REST URL will be different in case of raster layers or vect layers. We need at least a couple of URL in both cases:
     50  a. Raster layers:
     51   1. Creation of !CoverageStore
     52   1. Creation of Coverage
     53  a. Shape layers:
     54   1. Creation of !DataStore
     55   1. Creation of !FeatureType
     56
     57No layer name or other info will be asked to the user. We can make up this info in this way:
     58 * Layer name: the layer name is usually derived by GS from the file name. There may be problems of name uniqueness. They could be resolved by using GS' alias facility, but there seems to be problem in using aliases in REST configuration. At the moment this is an open problem.
     59 * SRS can be derived directly from ISO metadata. If such an info is not supplied (that field is optional in ISO), we will provide a predefined (hardcoded?) SRS.
     60
     61   
     62ETJ [[Timestamp]]
     63