Cas particuliers d'appariement

[XavDmz]

Dans la version 0.1.1, les traitements implémentés sont très basiques. Ils ne tiennent compte ni de la multiplicité des données utilisées lors de l'appariement, ni de la complexité de la géométrie.

Les cas suivants doivent donc être gérés correctement, selon les arbitrages du commanditaire :

• Sur un même millésime (année de prise de vue pour la télédétection, année d'installation effective pour les déclarations)
  • plusieurs géométries MultiPolygon issues de la télédétection (donc plusieurs objets de la table des détections) intersectent une même parcelle liée à une déclaration
    • Il s'agit d'un conflit
    • si le programme peut détecter ce cas, seul le lien d'appariement original est conservé. (Les nouveaux sont considérés invalides)
    • sinon, les liens sont cumulées. (Tous sont réputés valides.)
    • La détection de ce cas sera probablement compliquée, car la géométrie des déclarations n'est plus associée en détail à des parcelles lors de cette phase d'appariement.
    • Attention : il s'agit bien des géométries MultiPolygon (installations complètes), pas de leurs composantes Polygon (groupes de panneaux photovoltaïques).
  • ~~plusieurs objets issus des déclarations (id_dossier différents) recouvrent une même parcelle cadastrale
    • cas considéré comme une correction d'un dossier fermé.~~
    • seule la version la plus récente de l'objet est conservée (avec suppression au moins du lien avec l'objet remplacé)
    • Point d'attention : à différencier du cas simple où un même objet (id_dossier identique) subit effectivement une mise à jour sur le service source (donc la date de dernière modification a changé)
    • quand traiter ? lors de quelle étape, parmi
      • import depuis le service
      • géométrisation
      • éventuel export de données de déclarations si la base de données ou le schéma diffère entre les étapes de géométrisation et d'appariement (cas non pris en compte dans le programme, mais compatible avec le mode de configuration des traitements)
      • appariement
  • plusieurs objets issus des déclarations (id_dossier différents), mais sans parcelle commune, intersectent un même polygone dans la table des télédétections
    • cas traité comme une correction
    • seule la version la plus récente de l'objet est conservée (avec suppression au moins du lien avec l'objet remplacé)
  • plusieurs géométries Polygon issues de la télédétection (donc plusieurs objets de la table des détections) intersectent une même parcelle liée à une déclaration
  • "Cas normal pour ce type de géométries"
  • "Cumul des liens"
  • similaire au premier cas, mais avec les géométries simples. Cette déifférence de traitement est-elle pertinente ?
• Sur des millésimes différents
  • plusieurs objets issus des déclarations (id_dossier différents) recouvrent une même parcelle cadastrale
    • cas considéré comme une variation dans le temps
    • les différentes versions sont conservées, en lien avec l'objet de télédétection approprié
  • plusieurs objets issus des déclarations (id_dossier différents), mais sans parcelle commune, intersectent un même polygone dans la table des télédétections
    • cas traité comme une évolution
    • les différentes versions sont conservées, en lien avec l'objet de télédétection approprié

Si de nouveaux cas particuliers sont identifiés, ils seront éventuellement traités par des patchs correctifs.

EDIT :
La liste des cas a été simplifiée (voir #1 (comment)) :

• Plusieurs objets détectés intersectent une même parcelle déclarée
  • Ce cas est nominal.
  • L'objet "declaration" contenant la parcelle est donc lié à tous les objets "detection" qui l'intersectent.
• Plusieurs objets détectés intersectent une même déclaration
  • Comme le cas précédent, très similaire, ce cas est nominal.
  • L'objet "declaration" est donc lié à tous les objets "detection" qui l'intersectent.
• Un même polygone est détecté sur plusieurs millésimes
  • Cela signifie que plusieurs objets "detection" ont la même géométrie mais un millésime différent.
  • Ce cas est nominal.
  • Aucune action particulière n'est attendue.
• Plusieurs déclarations incluent une même parcelle
  • Ce cas est considéré comme un conflit, plus exactement la déclaration multiple d'une même installation. (Ça pourrait aussi en théorie être une déclaration de changement de l'installation, mais sur la période visée par le dispositif c'est peu probable.)
  • On ne conserve donc que la déclaration la plus récente, en tout cas dans la base GPF.
  • Si l'année d'installation est différente, on conserve les deux mais on applique uniquement le plus récent approprié lors de l'appariement avec un objet "detection". (Ce qui est la règle d'appariement de base.)
• Plusieurs déclarations croisent une même détection sur des parcelles différentes
  • Le cas peut théoriquement se présenter lorsques deux installations très proches l'une de l'autre sont réparties autour d'une frontière entre parcelles. En pratique ce cas semble trop rare, et ne sera pas pris en compte car il complique la cartographie.
  • Dans ce cas, on ne conserve que le lien avec la déclaration la plus récente pour chaque millésime.

Ces cas seront gérés par un exécutable dédié our par l'exécutable d'appariement, pour avoir accès à toutes les informations nécessaires aux choix décrits.
En utilisant les géométries fournies par l'API du service "Démarches Simplifiées", l'utilisation d'une bas de données cadastrales sera réduite voire nulle. Une telle base de donnée tierce amène en effet des incertitude sur l'actualité de ses données.

[XavDmz]

Pertinence de cette liste de spécifications à vérifier.

Il s'est passé des choses depuis son établissement et sa validation par les commanditaires il y a plus d'un an. En particulier, l'implémentation du code a beaucoup avancé, et il a pu être testé sur des données réelles dans leur modèle final. (ou proche)

[XavDmz]

Les cas identifiés jusqu'ici ont été passés en revue, en tenant compte des connaissances actuelles sur :

• Le sujet dans son ensemble
• Les spécifications définitives des données en entrée
• Les exemples de données réelles qui existent maintenant
• L'implémentation avancée du projet

Leur gestion a donc fortement été simplifiée. Les cas autrefois non-évidents qui restent sont les suivants :

• Plusieurs objets détectés intersectent une même parcelle déclarée
  • Ce cas est nominal.
  • L'objet "declaration" contenant la parcelle est donc lié à tous les objets "detection" qui l'intersectent.
• Plusieurs objets détectés intersectent une même déclaration
  • Comme le cas précédent, très similaire, ce cas est nominal.
  • L'objet "declaration" est donc lié à tous les objets "detection" qui l'intersectent.
• Un même polygone est détecté sur plusieurs millésimes
  • Cela signifie que plusieurs objets "detection" ont la même géométrie mais un millésime différent.
  • Ce cas est nominal.
  • Aucune action particulière n'est attendue.
• Plusieurs déclarations incluent une même parcelle
  • Ce cas est considéré comme un conflit, plus exactement la déclaration multiple d'une même installation. (Ça pourrait aussi en théorie être une déclaration de changement de l'installation, mais sur la période visée par le dispositif c'est peu probable.)
  • On ne conserve donc que la déclaration la plus récente, en tout cas dans la base GPF.
  • Si l'année d'installation est différente, on conserve les deux mais on applique uniquement le plus récent approprié lors de l'appariement avec un objet "detection". (Ce qui est la règle d'appariement de base.)
• Plusieurs déclarations croisent une même détection sur des parcelles différentes
  • Le cas peut théoriquement se présenter lorsques deux installations très proches l'une de l'autre sont réparties autour d'une frontière entre parcelles. En pratique ce cas semble trop rare, et ne sera pas pris en compte car il complique la cartographie.
  • Dans ce cas, on ne conserve que le lien avec la déclaration la plus récente pour chaque millésime.

De plus, au cours de mes réflexions, il m'est apparu plus simple de gérer ces cas a posteriori, et non lors de l'intégration des données sources. Cela pourrait être déplacé lors du calcul des liens d'appariement. L'important est d'avoir accès à toutes les informations en même temps.

Il apparaît aussi utile de s'affranchir le plus possible, de préférence totalement, de l'utilisation d'une donnée externe. En effet, cela éliminerait les incertitudes liées aux cycles de mise à jour des données cadastrales.