| 38 | |
| 39 | |
| 40 | ---- |
| 41 | Obsolete part ends here |
| 42 | ---- |
| 43 | |
| 44 | |
| 45 | 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. |
| 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 | |
| 57 | No 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 | |
| 62 | ETJ [[Timestamp]] |
| 63 | |