Je me suis permis de vérifier le référentiel en base pour le site web qui doit faire le lien entre les données de GEOFLAG, celle des XML et les informations de Camille Burette. Elle semble indiqué qu'elle a travaillé avec les données geoflag de 2011 et après vérification sur le site web et tout particulièrement sur les communes qui ont fusionné après 2016. Les communes reconnus étaient celle de 2011 et chaque commune était différencié au niveau des codes INSEE.

Cf.exemple : https://github.com/chartes/dico-topo/blob/master/data/DT02/DT02.xml

`

`

Autrefois seigneurie vassale de Montmirail. — La Celle dépendait des doyenné, archidiaconé, élection, subdélégation, prévôté et baill. de Sézanne, de l’intendance de Châlons et du dioc. de Troyes.

Elles sont entré de cette manière dans le code xml et suivent donc les configurations des données de 2011. Ils ont fusionnée en 2016 pour donner naissance à la commune de Dhuys et Morin-en-Brie et qui a le même code INSEE que la commune de Marchais.

Le problème est que sur le site les communes Fontenelle et Celle ne sont pas retrouvé sur la carte :

https://dicotopo.cths.fr/placenames/DT02-02355

https://dicotopo.cths.fr/placenames/DT02-01126

Donc j'ai peur que la carte du site utilise les données de 2018 alors que le travail réalisé par Camille Burette suit l'encodage INSEE de 2011.

Et le fichier communes-linking.py qui créé une partie de la base semble utiliser les informations de 2018 aussi comme on peut le voir avec la ligne :

28103 ark:/12148/cb15254034h

Elle référencie la ville de https://catalogue.bnf.fr/ark:/12148/cb15254034h qui a été créer en 2018.

Il est donc probable qu'il y ait un problème de compatibiltié entre le travail de Camille Burette et l'encodage du site mais cela mérite vérification plus profonde.

L’indentification automatique des communes des localisations échoue à environ 10%.
TODO : lever les codes erreurs et renseigner dans la mesure du possible @insee.
Erreurs

1. article_not_found: le renvoi ne correspond à aucune vedette
2. commune_is_empty: la balise commune est vide
3. insee_not_found: la vedette n’a pas de code insee
4. too_many_insee_codes: localisation correspondant à plusieurs vedettes

Analyse des fichiers XML des Pouillés

Décomptes et synthèse

Pagination

Par commodité, ajout de la pagination de chaque article dans article/@pg.

Vedettes

Les balises i rendent difficile l’extraction des vedettes :

• PO7-00004: <vedette><i>Abbaye</i> (<i>l’</i>)</vedette>
• PO7-03995: <vedette><i>Vauffelin</i>, en all. <i>Füglisthal</i></vedette>
• PO7-00053: <vedette><i>Alby</i> ou <i>Alby-sur-Chéran</i></vedette>
• PO7-02803: <vedette><i>Réchésy</i>, en all. <i>Röschlach</i> ou <i>Röschli</i></vedette>

Pire :

• PO7-00461: <vedette><i>Bonhomme</i> (<i>le</i>), en all. <i>Diedolshausen</i></vedette>
• PO7-00662: <vedette><i>Chaffal</i> (<i>le</i>), auj. <i>l’Escoulin</i></vedette>

Des exemples dans DT02 :

• DT02-00003: <vedette><sm>Abbaye (L’),</sm></vedette>
• DT02-00014: <vedette><sm>Abonval</sm> ou <sm>Ploisy,</sm></vedette>
• DT02-00944: <vedette><sm>Buisson (Le)</sm> ou <sm>Montabaudière,</sm></vedette>

Je propose de standardiser en suivant le modèle précédemment adopté :

• PO7-00004: <vedette><sm>Abbaye (l’)</sm></vedette>
• PO7-03995: <vedette><sm>Vauffelin</sm>, en all. <sm>Füglisthal</sm></vedette>
• PO7-00053: <vedette><sm>Alby</sm> ou <sm>Alby-sur-Chéran</sm></vedette>
• PO7-02803: <vedette><sm>Réchésy</sm>, en all. <sm>Röschlach</sm> ou <sm>Röschli</sm></vedette>
• PO7-00461: <vedette><sm>Bonhomme (le)</sm>, en all. <sm>Diedolshausen</sm></vedette>
• PO7-00662: <vedette><sm>Chaffal (le)</sm>, auj. <sm>Escoulin (l’)</sm></vedette>

Qu’en dites-vous ? Pas si trivial… cf PO7-00662.

Localisation

Schéma

La localisation est spécifiée dans un élément dédié pour chaque échelon administratif (très pratique), même si les valeurs peuvent être mal standardisées.

Le schéma diffère fortement sur ce point des DT. Je proposerais de réviser ce modèle. Par exemple :

<article old-id="PO7-02698" pg="649">
  <vedette><i>Pont-du-Doux</i></vedette>
  <localisationde>Ardèche</localisationde>
  <localisationca>c<sup>on</sup> de Tournon</localisationca>
  <localisationco>c<sup>ne</sup> de Saint-Barthélemy-le-Plein</localisationco>
  …
</article>

deviendrait (à revoir, pas top, cf segmentation de la commune – il faut analyser l’ensemble des balises).

<article old-id="PO7-02698" pg="649">
  <vedette><i>Pont-du-Doux</i></vedette>
  <definition>
    <localisation>
      <departement>Ardèche</departement>
      <canton>canton de Tournon</canton>
      <commune precision="approximatif" insee="07217">commune de Saint-Barthélemy-le-Plein</commune>
      <!-- 'Saint-Barthélémy-le-Plain' dans le COG 2011 -->
    </localisation>
  </definition>
  …
</article>

localisationpa

Unique pays de localisation, si PAS la France : Allemagne, Asie mineure, Italie, Palestine, Suisse

Un seul article avec localisationpa ET localisationde :

• PO7-01969 : pa = 'Suisse' / de = 'Haut-Rhin'.

210 articles sans localisationpa NI localisationde (//article[not(localisationde)][not(localisationpa)]) :

• doyenneté
• affluents
• ?

localisationde

(Ancien) Département de localisation.

2 articles avec 2 départements de localisation :

• PO7-02695: Isère + Savoie
• PO8-02447: Bouches-du-Rhône + Var

Liste étendue des valeurs possibles… Il va falloir normaliser les valeurs dans le code utile au liage :

• Ain
• Allier
• Alpes Maritimes
• Alpes-Maritimes
• Ardèche
• Aude
• Aveyron
• Bas-Rhin
• Basses-Alpes
• Basses-Pyrénées
• Bouches-du-Rhône
• Bouches-du-Rhône et Var
• Cantal
• Charente
• Charente-Maritime
• Cher
• Corrèze
• Côte-d’Or
• Creuse
• Dordogne
• Doubs
• Drôme
• Gard
• Gers
• Gironde
• Haut-Rhin
• Haute-Alpes
• Haute-Garonne
• Haute-Loire
• Haute-Marne
• Haute-Saône
• Haute-Savoie
• Haute-Vienne
• Hautes-Alpes
• Hérault
• Indre
• Indre-et-Loire
• Isère
• Jura
• Loir-et-Cher
• Loire
• Loiret
• Lot
• Lot-et-Garonne
• Lozère
• Maine-et-Loire
• Marne
• Meurthe-et-Moselle
• Nièvre
• Puy-de-Dôme
• Rhône
• Saône-et-Loire
• Savoie
• Seine
• Somme
• Tarn
• Tarn-et-Garonne
• Var
• Vaucluse
• Vienne
• Vosges
• Yonne
• territoire de Belfort

localisationco

Canton de localisation.

Analyser intérêt.

localisationco

Commune de localisation.

3 articles avec plusieurs communes de localisation :

• PO7-02635: Arnavon + Saint-Ferréol
• PO7-02932: Saint-Saphorin + Chardonne
• PO9-04206: Viala-du-Tarn + Saint-Rome-de-Tarn

localisation

Localisation indéfinie.

Par exemple :

• PO8-00098: <localisation>arr<sup>t</sup> de Grasse</localisation>

TODO: analyser

Formes anciennes

Une forme (fa) + sa ou ses référence(s) (reference).

fa

Contient la forme ancienne.

Italique

621 i hors vedette, par exemple :

• PO7-00180: <forme_ancienne><fa>Assinetz</fa>, <reference>304 var. <i>b</i></reference>.</forme_ancienne>
• PO7-01190: <compl>, localité disparue près de <i>Beauchastel</i></compl>
• PO7-02550: <renvoi>Voir <i>Saint-Sylvestre</i>.</renvoi>

D’accord pour conserver.

Exposant

405 sup hors localisationca et localisationco. – souvent des abréviations.

TODO: analyser

Renvois

Peut-on normaliser les renvois comme dans les DT et les insérer dans un commentaire ?

• DT02-04296: <renvoi>— Voy. <sm>Montreuil.</sm></renvoi>

<renvoi>Voir <i>Saint-Sylvestre</i>.</renvoi> (PO7-02550) deviendrait :

<commentaire>
  <p><renvoi>Voir <sm>Saint-Sylvestre</sm></renvoi>.</p>
</commentaire>

Doutes et corrections ?

compl

?

x

Souvent de la ponctuation : incertitudes de saisie ?

y

Des quadratins ajoutés devant la première forme ancienne d’un article ? Supprimer ?

z

Dans fa : restitution d’une forme ancienne ?

Ajout de DT15 par @CamilleArchives dans la branche ajout_element_commune.
Très nombreux problèmes de validation sur ce DT15 à reprendre sur la branche master.

TODO: dresser la liste des valeurs de typologie et déterminer si on peut normaliser et réduire cette liste. Inscrire alors la valeur correspondante dans typologie/@ft (pour feature type).
Exemple
<typologie>étang de 22 hectares</typologie> deviendrait
<typologie ft="etang">étang de 22 hectares</typologie>

Liste des erreurs récurrentes, en prévision d’une campagne de correction.
NB: il faut prévoir de superviser ces corrections.

• Contrôle des vedettes longues de plus de 30 caractères dans le terminal
• Remplacement des « precision="certaine" » par « precision ="certain" »
• Vérification de la segmentation des vedette/definition avec cet xpath : « //vedette//text()[not(ancestor::sm or parent::pg) and normalize-space(.)!=''] »
• Sortir les balises à l'intérieur des balises vedettes avec cette expression régulière :
  « \n + ([0-9]+) » à remplacer par « $1\n »
• Contrôle des inversions dans les balises localisatins avec les fichiers : « @DTXX_result_localisation_diff.csv» issue du script TestResultatDT.py

Au cours de l'étape 3, l'ajout de balise commune avec un code insee n'a pas été réalisé car la comparaison des chaînes de caractères entre la colonne du csv et le xml ne pouvait correspondre à cause de modifications effectuées par Python.

Le problème a été corrigè à partir du DT27 car les chaines de caractères ont été strippés, il faut donc reprendre du DT01 au DT26 pour rajouter les balises communes avec les codes insee manquants.

@architexte : peux-tu contrôler les @type inscrits pour les dpts listés en objet. Merci
par ex

<article type="commune" id="DT54-00001" pg="1">

DT62 n’est pas lié au référentiel insee.

TODO:

• ajouter les codes insee sur les communes
• enrichir localisation (lien code insee si possible)

Dans certains volumes, les vedettes sont saisies en majuscules.

• DT80 (des majuscules dans des balises sm !)
• DT60 (pas de balise sm, ce qui pose problème pour l’injection des données)
• ?
  TODO : normaliser le tout avant insertion en base (bascule MAJ -> min ?) – difficile…

Des renvois sont inscrits en commentaire des articles.
TODO: renseigner @corresp sur renvoi de manière à pointer vers l’identifiant de l’article référencé.

Les informations contenus dans les balises communes des DT doivent correspondre, dans la majorité des cas, aux labels INSEE.

Extraire les contenus des balises communes fautives et évaluer avec SN, OC et VJ quelles sont les balises qui doivent être modifier, supprimer ou conversever.

Messieurs @canteaut @architexte,

Certains cas particuliers trouvés dans la balise localisation demande une certaine expertise pour savoir ce que je dois faire avec :

• Cas des notions cantons, arrondissement qui sont suivi du nom d'une ville doivent-ils être ajouter comme des communes ou non

• On trouve aussi régulièrement la notion de "près de" qui peut être suivi de plein de données aussi bien une commune qu'un hameau ou autre donc il semble judicieux que ces données soient contrôlées.

• Il existe une ambiguité par rapport au cas qui précise un lieu par un site naturel Il peut s'agir d'un site naturel d'une commune comme Laruns qui est une commune du département :

  Gave de Bious (Le), ruisseau qui descend des montagnes de Laruns

Mais il peut aussi s'agir d'un nom qui ne soit pas lié aux communes :

<article id="DT64-04057" pg="119"> <vedette><sm>Mouscle (La),</sm></vedette> <definition><typologie>ruisseau</typologie> qui sort du <localisation>bois de Mourle</localisation>

Donc il est probable

La commune de la localisation est identifiée par @insee.
TODO : enrichir localisation/commune avec @corresp de manière à pointer vers l’article correspondant à cette commune identifiée par son code insee (@insee).

Plusieurs localisations, plus ou moins certaines :

• établir des règles pour retenir l’(unique) commune ajoutée par le nouvel auteur pour le liage INSEE.
• prévoir des règles éditoriales de reprise pour le chargement en base (suppression de ces conventions éditoriales très spécifiques) – à voir avec SN et OC.

Vérifier que tous les articles sont identifiés.
Comprendre sinon pourquoi.

• BD TOPO
• Lieux Cassini