Changes between Version 5 and Version 6 of GeoServer_integrationActivities

Timestamp:

Jun 19, 2008, 4:49:55 PM (16 years ago)

Author:

etj

Comment:

Obsoleted task table

GeoServer_integrationActivities

@@ +1 @@
+----
+
+'''THIS TABLE MAY BE OBSOLETE. '''
+
+Please read below.
+
+----
 
 == List of Activities for !GeoServer Integration ==
 
-GN = !GeoNetwork team
-
+GN = !GeoNetwork team [[BR]]
 GS = !GeoServer team
 
@@ -30 +36 @@
 ||  ||  ||  ||
 || 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, ...). ||
+
+
+----
+Obsolete part ends here
+----
+
+
+Given 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.
+
+ 1. A user edits a metadata, uploading the file as it is needed. Metadata also contains informations about layer type and SRS.
+ 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.
+ 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: 
+  a. Raster layers: 
+   1. Creation of !CoverageStore
+   1. Creation of Coverage
+  a. Shape layers: 
+   1. Creation of !DataStore
+   1. Creation of !FeatureType
+
+No layer name or other info will be asked to the user. We can make up this info in this way:
+ * 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.
+ * 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.
+
+   
+ETJ [[Timestamp]]
+