FEATURE: ✨Visit a church using a map (closes #369)

[CeyFun]

Content

Adds the feature described in #369.

---

Checklist

Please check that your pull request is correct:

• Each commit:
  • [x] corresponds to a contribution that should be notified to users,
  • [x] does not generate new errors or warnings at compile or test time,
  • [x] must be attributed to its real authors (with correct GitHub IDs and correct syntax for multiple authors).
• The title of a commit should:
  • [x] begin with a contribution type
    • FEATURE for a behaviour allowing a user to do something new,
    • FIX for a behaviour which has been changed in order to meet user’s expectations,
    • SCENARIO for examples showing a given behaviour,
    • TEST when it concerns an acceptance test of a given behaviour,
    • PROCESS for a change in the way the software is built, tested, deployed,
    • DOC when it concerns only internal documentation (however it is better to combine it with the contribution that required this documentation change),
  • [x] be followed by a colon (:) with one space after and no space before,
  • [x] be followed by a title (written in English) as short, as user-centered and as explicit as possible
    • If it is a feature, the title must be the user action (beginning with a verb, and please not manage),
    • If it is a fix, the title must describe the intended behavior (with should).
  • [x] ends with a reference to the corresponding ticket with the following syntax:
    • (closes #xx) if xx is a feature ticket (and the commit is a complete implementation),
    • (fixes #xx) if xx is a fix ticket (and the commit is a complete fix),
    • (see #xx) otherwise,
• Each committed line is:
  • [x] useful (it would not work if removed)
    • if it is a comment line, its information could not be conveyed by better variables and function naming, better code structuring, or better commit message,
  • [x] related to this very contribution (feature, fix...),
  • [x] in English (with the exception of Gherkin scenarios in French and resulting steps),
  • [x] without any typo in variable, class or function names,
  • [x] correctly indented (spaces rather than tabs, same number of characters as in the rest of the file).

[benel]

Merci @CeyFun pour cette impressionnante contribution !

Pour que le paramètre dans le fichier de configuration soit réellement utile, vous serait-il possible de le mettre dans une section dépendante du portfolio ? En effet, Porphyry est "multitenant" : la même instance est utilisée pour plusieurs sites. Ce serait embêtant que votre plugin soit actif par exemple pour tous les sites de la forme *.porphyry.org.

C'est ce que vos camarades ont mis en place pour les calques :

services:
  - ***
  - ***
map:
  key: ***
  geocodingService: ***
portfolio:
  vases:
    layers:
      - uri: ***
        bounds:
          south: ***
          west: ***
          north: ***
          east: ***
      - etc.

Avec une telle configuration, par exemple, les calques des nécropoles du Kerameikos ne sont ajoutées à la carte que quand le portfolio est "vases".

De même, vous pourriez activer le plan de l'édifice uniquement quand le portfolio est "vitraux". OK ?

[CeyFun]

Merci beaucoup pour le feedback @benel ! J'ai mis en place ce que vous avez dit avec en utilisant une configuration ressemblant à ceci :

services:
  - ***
  - ***
map:
  key: ***
  geocodingService: ***
portfolio:
  vitraux:
    visitMap: true

Cependant j'avais quelques doutes sur l'implémentation faite par l'autre équipe et me suis donc permis de vérifier si cela ne pose pas de problème, spécifiquement de ne pas avoir de layers pour un portfolio malgré la présence d'une carte style Google Maps. D'après mes rapides tests cela bug et j'en ai donc informé l'autre équipe ici.

Je me suis aussi permis de faire un git pull --force-with-lease afin de corriger le message de commit sans avoir à créer une nouvelle pull request, j'espère que cela ne vous dérange pas.

[benel]

Integrated as f68d4fedf3fa7b0ccafcb0f1a8f77db7fbb2962e 🎉