diff --git a/.gitignore b/.gitignore index b4130ea559..59f29e0cef 100644 --- a/.gitignore +++ b/.gitignore @@ -35,6 +35,7 @@ /doc/index.rst /doc/developer/server_side.rst /doc/integrator/create_application.rst +/doc/integrator/ngeo.rst /doc/integrator/upgrade_application.rst /dist/ /docker-compose.yaml diff --git a/doc/administrator/administrate.rst b/doc/administrator/administrate.rst index e994d00617..a927300495 100644 --- a/doc/administrator/administrate.rst +++ b/doc/administrator/administrate.rst @@ -80,9 +80,9 @@ All layer type All the layers in the admin interface have the following attributes: * ``Name``: the name of the WMS layer/group, or the WMTS layer. - It also used throw OpenLayers.i18n to display the name on the layers tree. + It is also used by OpenLayers.i18n, to display the name on the layers tree. * ``Public``: make the layer public, also it is accessible - throw the ``Restriction areas``. + through the ``Restriction areas``. * ``Restrictions area``: the areas through which the user can see the layer. * ``Related Postgres table``: the related postgres table, used by the :ref:`administrator_editing`. @@ -98,12 +98,12 @@ WMS layer On internal WMS layers we have the following specific attributes: * ``OGC Server``: the used server. -* ``Layers``: the WMS layers. Can be one layer, one group, a coma separated list of layers. - In the case of a coma separated list of layers, we will get the legend rule for the +* ``Layers``: the WMS layers. Can be one layer, one group, a comma separated list of layers. + In the case of a comma separated list of layers, we will get the legend rule for the layer icon on the first layer, and the legend will not be supported we should define a legend metadata. -* ``Style``: the used style, can be empty. +* ``Style``: the style used, can be empty. * ``Time mode``: used for the WMS time component. -* ``Time widget``: the used component type for the WMS time. +* ``Time widget``: the component type used for the WMS time. WMTS layer ~~~~~~~~~~ @@ -112,9 +112,9 @@ On WMTS layers we have the following specific attributes: * ``GetCapabilities URL``: the URL to the WMTS capabilities. * ``Layer``: the WMTS layer. -* ``Style``: the used style, if not present we use the default style. -* ``Matrix set``: the used matrix set, if there is only one matrix set - in the capabilities it can be empty. +* ``Style``: the style used; if not present, we use the default style. +* ``Matrix set``: the matrix set used; if there is only one matrix set + in the capabilities, it can be empty. layerv1 (deprecated in v2) ~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -126,7 +126,7 @@ The layers in the admin interface have the following attributes: * ``Checked``: the layer is checked by default. * ``Icon``: icon on the layer tree. * ``KML 3D``: optional, URL to a KML to display it on the Google earth view. -* ``Display legend``: it checked the legend is display on the layer tree. +* ``Display legend``: if checked, the legend is displayed on the layer tree. * ``Legend image``: URL to overwrite the default legend image. * ``Min/Max resolution``: resolutions between which data are displayed by the given layer, used to zoom to visible scale, with WMS if it is empty @@ -135,30 +135,30 @@ The layers in the admin interface have the following attributes: * ``Identifier attribute field``: field used to identify a feature from the layer, e.g.: 'name'. * ``Restrictions area``: the areas through which the user can see the layer. -On ``internal WMS`` layers we have the following specific attributes: +On ``internal WMS`` layers, we have the following specific attributes: * ``Image type``: the type of the images. -* ``Style``: the used style, can be empty. +* ``Style``: the style used, can be empty. * ``Dimensions``: a JSON string that gives the dimensions, e.g.: ``{ "YEAR": "2012" }``, if not provided default values are used. * ``Legend rule``: the legend rule used to get the layer icon, if empty we use the ``Icon``. -On ``external WMS`` layer we have the following specific attributes: +On ``external WMS`` layers, we have the following specific attributes: * ``Base URL``: the base URL of the WMS server. * ``Image type``: the type of the images. -* ``Style``: the used style, can be empty. +* ``Style``: the style used, can be empty. * ``Legend rule``: the legend rule used to get the layer icon, if empty we use the ``Icon``. * ``Single tile``: use the single tile mode. -On ``WMTS`` layer we have the following specific attributes: +On ``WMTS`` layers, we have the following specific attributes: * ``Base URL``: the URL to the WMTS capabilities. -* ``Style``: the used style, if not present we use the default style. -* ``Matrix set``: the used matrix set, if there is only one matrix set - in the capabilities it can be empty. +* ``Style``: the style used;, if not present, we use the default style. +* ``Matrix set``: the matrix set used; if there is only one matrix set + in the capabilities, it can be empty. * ``WMS server URL``: optional, URL to a WMS server to use for printing and querying. The URL to the internal WMS is used if this field is not specified. @@ -203,8 +203,8 @@ LayerGroup Attributes: -* ``Name``: used throw OpenLayers.i18n to display the name on the layers tree. -* ``Order``: used to order the layers and group on the layer tree. +* ``Name``: used by OpenLayers.i18n to display the name on the layer tree. +* ``Order``: used to order the layers and groups on the layer tree. * ``Metadata URL``: optional (deprecated in v2). * ``Expanded``: is expanded on the layer tree by default (deprecated in v2). * ``Internal WMS``: if true it can include only ``Internal WMS`` layers, diff --git a/doc/administrator/editing.rst b/doc/administrator/editing.rst index 38f8e7c6da..edb563ec86 100644 --- a/doc/administrator/editing.rst +++ b/doc/administrator/editing.rst @@ -6,14 +6,14 @@ Editing This section describes how to set up feature editing in c2cgeoportal applications. -Just like most administrative tasks setting up editing in a c2cgeoportal +Just like most administrative tasks, setting up editing in a c2cgeoportal application involves intervening in the database, through the c2cgeoportal administration interface. Requirements ------------ -To be editable a layer should satisfy the following requirements: +To be editable, a layer should satisfy the following requirements: 1. It should be accessible with WMS, and correctly configured in the mapfile. See :ref:`administrator_mapfile`. @@ -75,8 +75,8 @@ by selecting the *Layers* item in the admin interface's menu. For a *layer* to be editable its ``geoTable`` field should be set. This field is the name of the PostGIS table containing the layer's geographic data. It is -string of the form ``[.]``. If ``schemaname`` is -omitted the table is assumed to be in the ``public`` schema. The label +a string of the form ``[.]``. If ``schemaname`` is +omitted, the table is assumed to be in the ``public`` schema. The label corresponding to this field is *Related Postgres table* in the admin interface. .. warning:: diff --git a/doc/administrator/index.rst b/doc/administrator/index.rst index 87219578c1..09a00dba3c 100644 --- a/doc/administrator/index.rst +++ b/doc/administrator/index.rst @@ -9,7 +9,7 @@ application. The application administrator configures and administrates the application through the database. The administrator does not deal with the files of the -application (the integrator is the one responsible for these files). Except for +application (the integrator is the one responsible for these files), except for the map server files. Adding layers to the application indeed requires inserting information in the database, as well as adding layers in the map server. diff --git a/doc/administrator/mapfile.rst b/doc/administrator/mapfile.rst index d76a05300d..04cecc44e0 100644 --- a/doc/administrator/mapfile.rst +++ b/doc/administrator/mapfile.rst @@ -4,8 +4,8 @@ Mapfile configuration ===================== As mentioned on the index page (:ref:`administrator_guide`) the application -administrator manages the application through the database, and the -application's MapServer mapfile. +administrator manages the application through the database and via +the application's MapServer mapfile. The application's mapfile is where WMS and WFS layers are defined. WMS is used for the map (``WMS GetMap``), and for the ``point query`` feature (``WMS @@ -34,7 +34,7 @@ and/or *private* (a.k.a *restricted*). Print ----- -MapFish Print does single tile requests to the WMS server. For that reason we +MapFish Print performs single tile requests to the WMS server. For that reason we need to use a relatively large value for the ``MAXSIZE`` parameter (of the ``MAP`` section); 5000 for example. @@ -104,7 +104,7 @@ example:: .. warning:: The geometry columns of layers involved in ``box query`` should have the - same name. By default the WFS GetFeatue CGXP plugin + same name. By default the WFS GetFeature CGXP plugin (``cgxp_wfsgetfeature``) assumes the name is ``geom``, but the plugin can be configured to use a different name. @@ -150,7 +150,7 @@ example:: ``gml__type`` This specifies the type of a geometry column. Specifying this property is - necessary if geometries, instead of bboxes should be returned in + necessary if geometries, instead of bboxes, should be returned in GetFeatureInfo (GML) responses. ```` should be replaced the string set with the ``gml_geometries``. For example, if ``geom_geometries`` is set to ``the_geom`` then ``gml_the_geom_type`` should be used. @@ -166,23 +166,23 @@ See the `WMS Server MapFile Documentation Restricted layer ---------------- -The restricted layers work only with postgres data. All layer defined as +The restricted layers work only with PostgreSQL data. All layers defined as restricted in the mapfile should be defined as well in the admin interface and vice versa. With a RestrictionArea area ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -A RestrictionArea is used to restricted the layer displaying to a given area. +A RestrictionArea is used to restrict the layer displaying to a given area. This area is specified in the administration interface while defining the ``RestrictionArea`` element. .. warning:: - Using an restriction area on a big layer or defining a too complex area + Using a restriction area on a big layer or defining a very complex area may slow down the application. -To define a restricted layer in the Mapfile the ``DATA`` property of the +To define a restricted layer in the Mapfile, the ``DATA`` property of the ``LAYER`` should look like this:: DATA "the_geom FROM @@ -240,7 +240,7 @@ It is defined as follows: Without restriction on the RestrictionArea area ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If we do not need to restrict on an area we can use the following +If we do not need to restrict on an area, we can use the following ``DATA`` property of the ``LAYER``:: DATA "the_geom FROM ( @@ -300,7 +300,7 @@ Variable Substitution --------------------- It is possible to adapt some values in the mapfile according to the user's role -by using variable substitution. For instance to hide some layer objects +by using variable substitution, for instance to hide some layer objects attributes. The list of parameters that support variable substitution is available `here `_. @@ -311,7 +311,7 @@ section in the MapFile and add:: "s_" "" The ``validation_pattern`` is a regular expression used to validate the -argument. For example if you only want lowercase characters and commas, +argument. For example, if you only want lowercase characters and commas, use ``^[a-z,]*$``. Now in ``LAYER`` place ``%s_%`` where you want to @@ -320,7 +320,7 @@ insert the variable value, but not at the start of a line (to avoid escape issue Then in the administration interface, create a ``functionality`` named ``mapserver_substitution`` with the value: ``=``. -Please note that we cannot use substitution in the ``MATADATA`` values. +Please note that we cannot use substitution in the ``METADATA`` values. As a result, if you would like to adapt the list of attributes returned in a WFS GetFeature or WMS GetFeatureInfo request, you have to adapt the columns listed in the ``DATA`` section. For instance:: @@ -350,8 +350,8 @@ interface with for instance the following value for the given role: .. note:: - We are also able to use the ``role_id`` and ``user_id`` as - variable substitution, but they are not available for cached query like: + You can also use variable substitution for the ``role_id`` and ``user_id``, + but beware that these attributes are not available for cached queries like: ``GetCapabilities``, ``GetLegendGraphic``, ``DescribeFeatureType``. `MapServer documentation `_ @@ -403,8 +403,8 @@ because it saves MapServer from computing the extent of all layer features. Prepare raster files ~~~~~~~~~~~~~~~~~~~~ -To have good performance you should have tiled files with overview, and probably -a tileindex, you can doing these steps: +To achieve good performance, you should have tiled files with overview, and ideally +a tileindex, you can achieve this with these steps: Convert your rasters in tiled GeoTIFF: @@ -412,13 +412,13 @@ Convert your rasters in tiled GeoTIFF: gdal_translate -of GTiff -co "TILED=YES" -co "TFW=YES" -Then build overviews for your rasters +Then build overviews for your rasters: .. code:: gdaladdo -r average filename.tif 2 4 8 16 -You can generate a shapefile indexing all your rasters +You can generate a shapefile indexing all your rasters: .. code:: @@ -432,6 +432,6 @@ images and has memory leaks with ECW. See this `MapServer ticket `_ for example. -If you still want to use it then replace ``SetHandler fcgid-script`` +If you still want to use it, then replace ``SetHandler fcgid-script`` by ``SetHandler cgi-script`` in the ``apache/mapserver.conf.mako`` file. But note that this affects performance. diff --git a/doc/administrator/tinyows.rst b/doc/administrator/tinyows.rst index 1e05f89cb0..03802e3380 100644 --- a/doc/administrator/tinyows.rst +++ b/doc/administrator/tinyows.rst @@ -2,7 +2,7 @@ WFS-T with TinyOWS ================== -Based on `TinyOWS `__ c2cgeoportal layers can be +Based on `TinyOWS `__, c2cgeoportal layers can be edited via WFS-T, for example using QGIS as a client. c2cgeoportal acts as a proxy to TinyOWS to limit access to authorized users. @@ -83,8 +83,8 @@ In the root element ``tinyows`` the following properties have to be set: 4. ``log_level`` - The log level (default: 1). Please refer to the `TinyOWS documentation `__ for more information. -5. ``check_schema`` - If the input data is validated against the schema when - creating new features. In a vhost environment the schema check has to be +5. ``check_schema`` - Defines if the input data is validated against the schema when + new features are created. In a vhost environment, the schema check has to be disabled, so that the proxy can function properly. This does not disable the validation database-side though! @@ -105,7 +105,7 @@ The layers that should be accessible with TinyOWS have to specified with title="Points" pkey="id" /> -In this example a layer named ``point`` is created for table ``point`` in the +In this example a layer named ``point`` is created for the table ``point`` in the database schema ``edit`` with the primary key column ``id``. This layer is both ``retrievable`` and ``writable``. @@ -126,9 +126,8 @@ access to a layer to the users of a restriction-area. `TinyOWS documentation `__ for more information. -After the configuration is made, re-build the c2cgeoportal application:: +After the configuration is made, re-build your c2cgeoportal application as usual. - make docker-build Editing a layer with WFS-T -------------------------- diff --git a/doc/administrator/wmstime.rst b/doc/administrator/wmstime.rst index 521afd3ffa..61dba6d8c7 100644 --- a/doc/administrator/wmstime.rst +++ b/doc/administrator/wmstime.rst @@ -36,7 +36,7 @@ date, an end date and an interval between the time stops. The format ``value1,value2,value3,...`` allows specifying a time range by listing discrete values. -The dates (``min``, ``max`` and ``valueN``) could be specified using any of the +The dates (``min``, ``max`` and ``valueN``) can be specified using any of the following formats: * ``YYYY`` @@ -50,8 +50,8 @@ requests. For example when a layer has monthly data, the ``YYYY-MM`` should be used in the mapfile to make sure that only months and years are displayed in the slider tip and passed to the GetMap request. -The interval (``interval``) has to be defined regarding international standard -ISO 8601 and its duration/time intervals definition (see +The interval (``interval``) has to be defined according to the +ISO 8601 standard and its duration/time intervals definition (see `ISO 8601 Durations / Time intervals `_). Some examples for the interval definition: @@ -59,7 +59,7 @@ Some examples for the interval definition: * An interval of one year: ``P1Y`` * An interval of six months: ``P6M`` -For more information please refer to the `MapServer documentation +For more information, please refer to the `MapServer documentation `_. Admin interface @@ -71,7 +71,7 @@ Two different widget types are available: A time slider and a datepicker widget. The preferred widget can be selected in the admin interface (field ``Time widget``). -Besides, the time mode can be changed. The time mode is one of: +Note that the time mode can be changed. The time mode is one of: * ``value`` * ``range`` @@ -108,5 +108,5 @@ Some of those limitations apply to the mapfile: There is also a limitation that applies to the admin interface: all the WMS Time layers of a group should be configured to use the same widget and the same time mode -(``single`` or ``range``) except for layers with time mode ``disabled`` that can be mixed +(``single`` or ``range``), except for layers with time mode ``disabled`` that can be mixed within others. diff --git a/doc/index.rst.mako b/doc/index.rst.mako index dc78eb3d6a..678f053e4f 100644 --- a/doc/index.rst.mako +++ b/doc/index.rst.mako @@ -31,7 +31,7 @@ One of the primary goals of the c2cgeoportal project is sharing as much as functionality and code as possible between applications. *Do not repeat ourselves!* -`Demo `_, +`Demo `_, `with features grid `_, to test the editing you can use the username 'demo' with the password 'demo'. diff --git a/doc/integrator/create_application.rst.mako b/doc/integrator/create_application.rst.mako index 3dde29b446..d627125e68 100644 --- a/doc/integrator/create_application.rst.mako +++ b/doc/integrator/create_application.rst.mako @@ -23,7 +23,7 @@ that is already alongside the existing c2cgeoportal application. Project structure ----------------- -In the simple case the root directory of the application is the directory +In the simple case, the root directory of the application is the directory created by the c2cgeoportal scaffolds (the ``c2cgeoportal_create`` and ``c2cgeoportal_update`` scaffolds). @@ -50,7 +50,7 @@ To get ``c2cgeoportal``, you need to get the related docker image: List existing scaffolds ----------------------- -To list the available scaffolds use the following command, either +To list the available scaffolds, use the following command, either from the root directory of c2cgeoportal (if you have followed the instructions from the previous section), or from the root directory of the existing c2cgeoportal application you want to create the new application from: @@ -78,7 +78,7 @@ Normally the project name should be the same name as the Git repository name. The package name should not contain an underscore (``_``) because of an issue with Pip. -To create the application first apply the ``c2cgeoportal_create`` scaffold: +To create the application, first apply the ``c2cgeoportal_create`` scaffold: .. prompt:: bash @@ -156,7 +156,7 @@ Put the application under revision control ------------------------------------------ Now is a good time to put the application source code under revision -control (Git preferably). +control (Git, preferably). To add a project in a new repository .................................... @@ -204,7 +204,7 @@ and in vars files as follows: extends: CONST_vars.yaml -``CONST`` files are files that should not be changed because they are replaced +``CONST`` files are files that should not be changed, because they are replaced during application updates, so your changes will be systematically lost. You can extend these files as many times as you like, although it is not recommended to exceed 3-4 levels for readability and simplicity. @@ -259,7 +259,7 @@ environment variables: Configure the application ------------------------- -As the integrator you need to edit the ``vars.yaml`` and +As the integrator, you need to edit the ``vars.yaml`` and ``.mk`` files to configure the application. Do not forget to add your changes to git: @@ -312,7 +312,7 @@ Then follow the sections in the install application guide: .. note:: - After that if you want a default theme you can run: + If you want a default theme, you can run: .. prompt:: bash @@ -353,6 +353,6 @@ In ``.mako`` files, the variable replacement syntax is as follows: ${'$'}{} -for example: +For example: * ``${'$'}{directory}`` diff --git a/doc/integrator/install_application.rst b/doc/integrator/install_application.rst index 2cc061c72a..e5106f8213 100644 --- a/doc/integrator/install_application.rst +++ b/doc/integrator/install_application.rst @@ -4,7 +4,7 @@ Install an existing application =============================== On this page we explain the procedure to build an application from -only the code. +only the current application code. If you want to use an existing database, you should ignore all the commands concerning the database. @@ -47,7 +47,7 @@ with ```` replaced by the actual database name. .. note:: - if you do not have the template_postgis you can use: + If you do not have the template_postgis you can use: with Postgres >= 9.1 and PostGIS >= 2.1: @@ -67,8 +67,8 @@ with ```` replaced by the actual database name. Note that the path of the postgis scripts and the template name can differ on your host. -Create the "pg_trgm" extension to use the "similarity" function within the -full-text search: +If you wish to use the "similarity" function within the +full-text search, create the ``pg_trgm`` extension: .. prompt:: bash @@ -229,7 +229,7 @@ on RedHat Enterprise Linux (RHEL) 6. application in your homedir. If you do so, you will get the following error in the Apache logs:: - (13)Permission denied: access to /~elemoine/ denied + (13)Permission denied: access to /~/ denied So always install the application in an Apache-accessible directory. On Camptocamp *puppetized* servers you will typically install the application @@ -283,11 +283,11 @@ This previous command will do many things like: Your application should now be available at: -``https:///``. +``https:///``, +where the ```` is directly linked to the virtual host. -Where the ```` is directly linked to the virtual host. - -Add in the ``/var/www/vhosts//conf/proxies.conf`` file (create it if not exist): +Add in the ``/var/www/vhosts//conf/proxies.conf`` file +(create it if it does not exist): .. code:: @@ -298,7 +298,7 @@ Add in the ``/var/www/vhosts//conf/proxies.conf`` file (create it if RequestHeader set X-Forwarded-Port "443" ProxyRequests Off -The root instace should be at the end. +The root instance should be at the end. Migrating to a new server ------------------------- diff --git a/doc/integrator/make.rst b/doc/integrator/make.rst index f2f5e46400..6c86435e77 100644 --- a/doc/integrator/make.rst +++ b/doc/integrator/make.rst @@ -6,14 +6,14 @@ Build configuration Makefiles --------- -Usually we have the following makefiles includes: +Usually we have the following makefile includes: ``.mk`` -> ``.mk`` -> ``CONST_Makefile.mk``. The ``CONST_Makefile.mk`` is a huge makefile that is maintained by the GeoMapFish developers. The ``.mk`` contains the project-specific config and rules, -Default is: +default is: .. code:: makefile @@ -48,13 +48,14 @@ To make such variables available to the python code, for instance using they must be listed in the makefile as well using ``CONFIG_VARS`` (see below). -To get a variable from the makefile to the vars, you should make your variable as export: +To be able to use a variable from the makefile in the vars file, +you should export your variable as follows: .. code:: make export MY_VAR ?= my_value -And in your yaml vars file add: +And in your yaml vars file, add: .. code:: yaml @@ -67,8 +68,8 @@ And in your yaml vars file add: - ... - my_var -For more information see the -`c2c.template `_ documentation. +For more information, see the +`c2c.template `_ documentation. Makefile config variables @@ -121,21 +122,21 @@ To decrypt the files run: .. note:: - If you have an issue that call about the ``dirmngr`` package you can try to add: + If you have an issue with the ``dirmngr`` package you can try to add: ``pinentry-mode loopback`` in your ``~/.gnupg/gpg.conf`` file and ``allow-loopback-pinentry``in your ``~/.gnupg/gpg-agent.conf`` file. - Than it should be fixet or you can also try to run it in Docker: + Then it should be fixed or you can also try to run it in Docker: ``./docker-run --home make --makefile=.mk secrets`` - If you have an error about opennig ``/dev/tty`` try to run it in Docker as root: + If you have an error about opening ``/dev/tty``, try to run it in Docker as root: ``./docker-run --root --home make --makefile=.mk secrets`` Custom rules ------------ -In the ``.mk`` file we can create some other rules. -Here is a simple example: +In the ``.mk`` file, you can create custom rules. +Here is an example: .. code:: makefile @@ -157,7 +158,7 @@ Here is a simple example: Note ---- -The ``/build/*.timestamp`` files are not really required but they are flags -indicating that an other rule is correctly done. +The ``/build/*.timestamp`` files are flags +indicating that another rule is correctly done. Upstream `make documentation `_. diff --git a/doc/integrator/ngeo.rst b/doc/integrator/ngeo.rst.mako similarity index 90% rename from doc/integrator/ngeo.rst rename to doc/integrator/ngeo.rst.mako index 278cf37d03..f99d184f86 100644 --- a/doc/integrator/ngeo.rst +++ b/doc/integrator/ngeo.rst.mako @@ -23,7 +23,7 @@ The style sheet file for a specific interface is ``/static-ngeo/less/`_ +* ``wfs_permalink``: additional values for the ``ngeoWfsPermalinkOptions`` constant, see: + `ngeox.WfsPermalinkOptions `_ for more information. diff --git a/doc/integrator/requirements.rst b/doc/integrator/requirements.rst index ff9aea7d2a..6ef306e869 100644 --- a/doc/integrator/requirements.rst +++ b/doc/integrator/requirements.rst @@ -3,7 +3,7 @@ Requirements ============ -To install a GeoMapFish application you need to have the following +To install a GeoMapFish application, you need to have the following components installed on your system: * **Git** (preferably to other revision control systems) @@ -54,10 +54,10 @@ Print ~~~~~ The print requires a Tomcat server listening by default on port 8080. -To change it you should overwrite the ``print_url`` vars in ``config.yaml.in``, +To change this, you can overwrite the ``print_url`` vars in ``config.yaml.in``, default is: ``http://localhost:8080/print/pdf/``. -MapFishPrint must be installed in version 3 or later. +MapFish Print must be installed in version 3 or later. Additional notes for Windows users ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/integrator/upgrade_application.rst.mako b/doc/integrator/upgrade_application.rst.mako index 4eb00bd5fa..49aa2528b9 100644 --- a/doc/integrator/upgrade_application.rst.mako +++ b/doc/integrator/upgrade_application.rst.mako @@ -8,7 +8,7 @@ Upgrading a GeoMapFish application From a version 2.2 ~~~~~~~~~~~~~~~~~~ -If you have some custom Angular components you should first follow these instructions: +If you have some custom Angular components, you should first follow these instructions: `Migration from ngeo 2.2 to ngeo 2.3 `_ @@ -50,7 +50,7 @@ Prepare the upgrade: .. note:: - If the last command failed you should create the ``project.yaml`` file + If the last command failed, you should create the ``project.yaml`` file from the ``project.yaml.mako`` file. For Docker (recommended): @@ -85,7 +85,7 @@ Then follow the instructions. Please make sure you have the correct access rights and the repository exists. - you can fix it by using the following command: + you can fix it by using the following command, .. prompt:: bash @@ -191,38 +191,40 @@ Layer definition for ngeo clients is separate and different from layer definition for CGXP clients, see :ref:`administrator_administrate_layers` for details. To migrate the layer definitions from the CGXP structure to the ngeo -structure, you can use the script themev1tov2. +structure, you can use the script ``themev1tov2``. -In non docker context, run the script from venv: +In a docker project, run the script from geoportal service: .. prompt:: bash - .build/venv/bin/themev1tov2 -i geoportal/production.ini + docker-compose up -d + docker-compose exec geoportal themev1tov2 -In docker context, run the script from geoportal service: +In a non docker project, run the script from venv: .. prompt:: bash - docker-compose up -d - docker-compose exec geoportal themev1tov2 + .build/venv/bin/themev1tov2 -i geoportal/production.ini + Text translations for ngeo clients are separate and different from text translations for CGXP clients. -To migrate the text translations from CGXP to ngeo, you can use the script - +To migrate your text translations from CGXP to ngeo, you can use the script ``.build/venv/bin/l10nv1tov2``. -For example, for converting french texts, in non docker context, the script can -be used as follows: -.. code:: bash - - .build/venv/bin/l10nv1tov2 fr geoportal/_geoportal/static/js/Proj/Lang/fr.js \ - geoportal/locale/fr/LC_MESSAGES/geoportal-client.po - -In docker context, run the script using docker-compose-run: +In a docker project, run the script using docker-compose-run +(example for converting french language texts): .. prompt:: bash docker-compose up -d ./docker-compose-run l10nv1tov2 fr geoportal/_geoportal/static/js/Proj/Lang/fr.js \ geoportal/_geoportal/locale/fr/LC_MESSAGES/geoportal-client.po + + +In a non docker project, the script can be used as follows: + +.. prompt:: bash + + .build/venv/bin/l10nv1tov2 fr geoportal/_geoportal/static/js/Proj/Lang/fr.js \ + geoportal/locale/fr/LC_MESSAGES/geoportal-client.po