Add access column - Githubissues

loicgasser commented 10 years ago

in view_bod_layerinfo{lang} in view_layers_js

@ltclm Could you do that?

I'll adapt in chsdi afterwards. (we have this column only in catalog table at the moment, which is not very helpful)

Thanks!

ltclm commented 10 years ago

Hi Loic I have added the column acces (coming from google-spreadsheet -> bod.re3.catalog.access) to the following views:

bod.re3.view_layers_js
bod.re3.view_bod_layerinfo{lang}
bod.re3.view_bod_wmtsgetcapabilities{lang}

Since the getcap service and model is still using the column bod.public.dataset.projekte to filter projects like 'swissmaponline' etc. we still cannot remove the column from the bod. We have to find another solution. We could make a projects table and a xt_layers_projects table to manage the link between layers and projects. @gjn @procrastinatio @AFoletti @loicgasser any ideas and suggestions are welcome.

ltclm commented 10 years ago

A possible solution to remove the bod.public.dataset.projekte column could be:

add new junction table bod.re3.xt_layers_js_projects
add new projects table bod.re3.projects
import the information from bod.public.dataset.projekte into this structure

The future scheme could look like this:

             +-----------------+                                              
             |bod.re3.projects |                                              
             +-----------------+                                              
            1|                 |                                              
+------------+ * project       |                                              
|            |                 |                                              
|            | more project att|                                              
|            +-----------------+                                              
| db                                                                          
| constraint                                                                  
|                                                                             
|       +-----------------------------+                                       
|       |bod.re3.xt_layers_js_projects|                                       
|      n+-----------------------------+                                       
+-------+ * fk_projects               |                                       
       n|                             |                                       
+-------+ * fk_layer                  |                                       
|       +-----------------------------+                                       
|                                                                             
| db                                                                          
| constraint                                        +------------------------+
|           +--------------------+                  | bod.re3.catalog        |
|           | bod.re3.layers_js  |      view        +------------------------+
|           +--------------------+                  |                        |
|         1 |                    +------------------+ layer                  |
+-----------+ * pk_layer         |                  |                        |
            |                    |           +------+ topic                  |
            +--------------------+           |      |                        |
                                             |      +------------------------+
                                             |                                
                                       view  |      +------------------------+
                                             |      | bod.re3.topics         |
                                             |      +------------------------+
                                             +------+ * topic                |
                                                    |                        |
                                                    |                        |
                                                    |                        |
                                                    +------------------------+

The relation between layers_js, topics and catalog will not change, it is a view only relation, no db-constraints. The relation between layers_js and projects, or lets say flat catalogs will be controlled by foreign keys. the api topic should be moved into the projects table, The google Spreadsheet would only be used for the maintenance of the catalog, topic and gui stuff.

What do you think?

loicgasser commented 10 years ago

I like it. We ll be a lot more flexible with this approach and it fixes the issues we have with api-free not-fre swissmaponline etc... please proceed

gjn commented 10 years ago

So the topic we have in our service urls [1] will be a combination of both topic and projekte?

Our clients (map.geo.admin.ch and API) both use the services in that way. For that point of view, api and ech are the same. Where they differ is that api is not a topic in map.geo.admin.ch and does not have a catalog.

I would rather get rid of the notion of 'projekte' and make api, swissmaponline, wms etc as topics as well, just topics without a catalog. In map.geo.admin.ch, a topic is choosable only if it has a catalog.

To have LayersConfig for non-catalog topics, a seperate mechanism (similar to xt_layers_js_projects) could be used.

Does the following 3 principle work? 1) a topic is a collection of layers with associated services (layersconfig, search, find, etc) 2) a catalog is just one represantation (view) of a topic 3) not all topics have a catalog

[1] https://api3.geo.admin.ch/rest/services/api/MapServer/...

AFoletti commented 10 years ago

I tend to agree with @gjn. The "projekte" notion is now only a special filter for special issues (swissmaponline) and we should find a way to get rid of this. swissmaponline is, de facto, our third (important) client and I think it would made sense to have it as a topic. This means break the layer-catalog-topic dependence we have today (a layer can be used only if it's in a catalog), which looks very good to me (will allow us to activate layers in PROD without having them visible in any catalog)

gjn commented 10 years ago

Also, our topics service [1] already contains a parameter showCatalog which could easily be used to determine if a topic has a catalog or not.

This service should/could be extended to specify which services are available for a specific topic.

[1] https://api3.geo.admin.ch/rest/services

ltclm commented 10 years ago

Thanks for your input. I agree with @gjn and @AFoletti, we should get rid of the projekte notion. We could implement a scheme like this:

                                                   +------------------------+          
           +--------------------+                  | bod.re3.catalog        |          
db         | bod.re3.layers_js  |      view        +------------------------+          
constraint +--------------------+                  |                        |          
         1 |                    +------------------+ layer                  |          
 +---------+ * pk_layer         |                  |                        |          
 |         |                    |                  | topic                  +----+     
 |         +--------------------+                  |                        |    |     
 |                                                 +------------------------+    |     
 |                                                                               | view
 |    +-----------------------------+              +------------------------+    |     
 |    |bod.re3.xt_layers_js_topics  |  db          | bod.re3.topics         |    |     
 |   n+-----------------------------+  constraint 1+------------------------+    |     
 +----+ * fk_layer                  |      +-------+ * topic                +----+     
      |                             |n     |       |                        |          
      | * fk_topic                  +------+       |                        |          
      |                             |              |                        |          
      |   access                    |              +------------------------+          
      +-----------------------------+

Which means:

the table bod.re3.xt_layer_js_topics will contain the information which is now in bod.public.dataset.projekte, so the flat catalog mapping will be here. It could also contain layer-topic specific informations like access in case of api layers. layer->catalog mappings should not be here, this is done in the catalog table which is managed in the google spreadsheet.
the table topics will also contain the projekte or flat catalog like 'api', 'swissmaponline', etc.
We could add an attribute "type" to the topics table which will be 'catalog' or 'group'. In case of catalog, the catalog specific attributes like background_layers, show_catalog, ... can be set, if not they have to be null.

procrastinatio commented 10 years ago

Our layers are unique, for most services there is no difference for the same layer between the topics

/rest/services/api/MapServer
/rest/services/api/MapServer/{layerBodId}
/rest/services/api/MapServer/{layerBodId}/legend
/rest/services/api/MapServer/find
/rest/services/api/MapServer/{layerBodId}/{featureId}/htmlPopup

etc...

Out topicis taken from ESRI map, in where the same layer may have a different styling for instance.

loicgasser commented 10 years ago

Changes in BOD so far:

add column ‘chargeable’ to bod.public.dataset
remove column ‘access’ from bod.re3.xt_dataset_topics
add “flat” topics swissmaponline and api to bod.re3.topics
copy api and swissmaponline layer mapping to bod.re3.xt_dataset_topics
remove api from bod.public.catalog
bod.re3. view_bod_layer_info_xx
- datasource for topics column is now bod.re3.xt_dataset_topics and bod.re3.catalog
- add column chargeable ‘true|false’
bod.re3.view_bod_wmts_getcapabilities_xx
- add column topics (same configuration as in bod.re3.view_bod_layer_info_xx)
- add column chargeable (same configuration as in bod.re3.view_bod_layer_info_xx)
bod.re3.view_layers_js
- datasource for topics column is now bod.re3.xt_dataset_topics and bod.re3.catalog
- add column chargeable ‘true|false’

cedricmoullet commented 9 years ago

This can't be deployed before accident map

cedricmoullet commented 9 years ago

Will be deployed next week

loicgasser commented 9 years ago

This issue can be closed since https://github.com/geoadmin/mf-chsdi3/pull/978 has been merged

geoadmin / mf-chsdi3

Add access column #891