Closed loicgasser closed 9 years ago
Hi Loic I have added the column acces (coming from google-spreadsheet -> bod.re3.catalog.access) to the following views:
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.
A possible solution to remove the bod.public.dataset.projekte column could be:
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?
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
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/...
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)
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.
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:
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 topic
is taken from ESRI map
, in where the same layer may have a different styling for instance.
Changes in BOD so far:
This can't be deployed before accident map
Will be deployed next week
This issue can be closed since https://github.com/geoadmin/mf-chsdi3/pull/978 has been merged
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!