| | 35 | We may provide an implementation for the following use case: |
| | 36 | |
| | 37 | 1. A user edits a metadata, uploading the file as it is needed. Metadata also contains informations about layer type and SRS. |
| | 38 | 2. 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. |
| | 39 | 3. 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: |
| | 40 | 1. Raster layers: |
| | 41 | 1. Creation of CoverageStore |
| | 42 | 2. Creation of Coverage |
| | 43 | 2. Shape layers: |
| | 44 | 1. Creation of DataStore |
| | 45 | 2. Creation of FeatureType |
| | 46 | |
| | 47 | No layer name or other info will be asked to the user. We can make up this info in this way: |
| | 48 | |
| | 49 | * 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. |
| | 50 | * 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. |
| | 51 | |
| | 52 | |
