On a des définitions légales des zones de compétence des tribunaux d'instance et de grande instance, par exemple :
http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000022727541 Il me semble que pour les tribunaux de grande instance les divisions correspondent aux départements (sauf exception à vérifier). Mais pour les tribunaux d'instance simples cela ne correspond pas aux arrondissements mais ce sont des regroupements de cantons. Pour cartographier les tribunaux d'instance on devrait avoir dans OSM les boundary=judiciary, éventuellement avec un tag judiciary_type=FR:instance (et peut-être aussi judiciary_type=FR:grande_instance qui regroupent les zones de plusieurs tribunaux d'instance, et FR:appel, ou FR:cassation, et FR:prud'hommes... à voir). Evidemment il faudrait continuer à cartographier les cantons manquants (la plupart de ceux qui manquent sont soit dans les départements où il manquie encore beaucoup de commune, ou bien sont ceux où des communes sont divisées en fractions cantonales. Mais on pourrait imaginer avoir un découpage de ces cantons à la façon de l'INSEE, en tant que "canton_ou_ville" à usage statistique, dont on exclue les communes découpées sur plusieurs cantons, et qui ont en revanche des statistiques au niveau de la commune entière). Mais comment distinguer ces pseudo-cantons statistiques de l'INSEE permettant de combler les trous si on met pour eux aussi boundary=political et political_division=canton ? Ne pourrait-on pas avoir des objets pour les fractions cantonales d'une commune, et alors ajouter des tags pour leur utilisation statistique (sans fractionnement des communes qui dès lors sopnt comptées à part) quand elle est distinguée de l'utilisation pour les élections ? OK il nous faudrait combler les trous des *vrais* cantons mais c'est long et compliqué à chercher sur LegiFrance (il faut repérer chacune des rues et faire très attention à leur définition, souvent ancienne, quand les rues ont parfois changé de nom depuis sans que le texte initial n'ait été modifié... il faut alors chercher dans les archives des décisions municipales... pas toutes en ligne). En attendant on a besoin aussi de ces canton_ou_ville statistiques (boundary=statistical, statistical_division=canton_ou_ville, la même relation pouvant avoir les deux rôles quand un canton n'a pas de fraction de commune, sinon la commune divisée aura aussi ce rôle, et dans les deux cas on ne mettra pas boundary=statistical, mais soit boundary=political pour les cantons simples, soit boundary=administrative+admin_level=8 pour les communes fractionnées : cela simplifie le nombre d'objets à créer mais permet alors de trouver ces pseudo-cantons, qui ont le même code INSEE à 4 chiffres que le vrai canton pour les cantons partiels sans les communes divisées, et le même code INSEE à 5 chiffres que la commune pour les communes divisées qu'il faut pouvoir repérer). Ensuite selon l'usage : (1) statistique: rechercher l'union de: - "boundary=political" ET "political_division=canton" ET avec statistic_division=canton_ou_ville (pour les cantons simples sans commune fractionnée sur plusieurs cantons, il n'y a pas de relation "dupliquée") - "boundary=statistical" ET "statistic_division=canton_ou_ville" (pour un pseudo-cantons partiel : la ref:INSEE est le même code à 4 chiffres son vrai canton complet et a "political_division=canton" mais PAS "statistic_division=canton_ou_ville") - "boundary=administrative" ET "admin_level=8" ET "statistic_division=canton_ou_ville" (pour le pseudo-canton statistique d'une commune fractionnée) - L'union des trois types peut se faire en cherchant uniquement sur la seule condition très simple: "statistic_division=canton_ou_ville" (2) électoral: rechercher uniquement: - boundary=political & political_division=canton, MAIS SANS statistic_division=canton_ou_ville (comme maintenant) Les regroupements de cantons ignorent (je pense) le cas des communes fractionnées qui entrent entièrement dans le regroupement (quitte à unir plusieurs cantons dans leur totalité afin d'effacer le fractionnement électoral). Cela me semble être le cas du découpage judiciaire, mais je peux me tromper. Sur Layers.openstreetmap.fr, il serait bon de supprimer "Canton & Politique" qui ne concerne que le découpage français, et de ne garder que la couche "boundary=political" avec laquelle la couche fait réellement doublon pour rien (sauf qu'elle se restreint inutilement à la Franche seulement (l'autre couche montre des divisions utilisées dans les autres pays, même si elles sont de natures différentes pour political_division=*, Layers pouvant très bien continuer à utiliser plusieurs couleurs selon qu'il fait l'union de plusieurs types différents comme ici en France). Je pense en revanche que les couleurs de l'actuelle couche "Canton & Pollitique" sont plus lisibles que les couleurs ambigues de la couche "boundary=political". En revanche on devrait y trouver: - la nouvelle couche boundary=judiciary (utilisée et pratiquement complète déjà en Belgique et applicable aussi en France et à d'autres pays européens) - la nouvelle couche boundary=postal_code (très développée en Allemagne et applicable aussi à la France et de nombreux pays) : ces zones donnent de meilleurs résultats pour géolocaliser les codes postaux car d'une part des communes ont souvent plusieurs codes postaux dans des zones distinctes, et on ne peut pas les distinguer autrement que noeud par noeud actuellement en France (ce qui rend les recherches par code postal assez aléatoires). Ces deux couches seraient très utiles, surtout la seconde pour les codes postaux qui sont bien mieux connus par le grand public que les codes INSEE, et présents dans tous les fichiers d'adresses à géolocaliser : on ne devrait pas avoir à chercher par une heuristique basée sur les noeuds les plus proches, surtout quand on ne sait pas dans quel périmètre les chercher, ce qui prend alors un temps considérable et donne de mauvais résultats dans Nominatim en France (alors qu'ils sont très bons en Allemagne. Oui dans un premier temps on aura des trous, mais une bonne partie de la carte des codes postaux peut être générée par un script cherchant les communes qui n'ont qu'un seul code postal dans leur relation (et vérifiant que les noeuds de leur admin_centre correspond bien, ce qui n'est pas toujours le cas car la relation peut mentionner plusieurs codes postaux et le noeud ne peut en préciser qu'un seul !). La question sera alors de savoir si on doit aussi ajouter les codes CEDEX dans les relations des communes (on n'en met pas sur les noeuds, mais pourquoi pas si on géolocalise un établissement d'une entreprise ou administration dont l'adresse postale est un CEDEX différent du code postal de la commune où l'établissement est situé, le CEDEX n'indiquant pas la position réelle de la boîte à lettre ou du lieu de distribution, mais la destination d'un courrier destiné à l'entreprise de l'établissement géoréférencé...) Un problème avec les codes postaux français : on ne peut apparemment pas importer directement le fichier de la Poste (il faudrait un accord de licence de l'ARCEP si c'est l'ARCEP qui maintenant s'en occupe pour tous les opérateurs postaux en concurrence, de la même façon qu'il s'occupe du plan de numérotation téléphonique qui n'est plus de la compétence de France Télécom). Mais j'ai beau chercher sur le site de l'ARCEP, je ne vois pas de référence à ce fichier : est-ce que les codes postaux ne sont à l'usage QUE de La Poste (les autres opérateurs pouvant avoir leur propre codification pour gérer leur réseau de distribution), et La Poste en serait resté propriétaire exclusif ? Il y a quelques années il fallait payer pour avoir le droit légal d'utiliser le fichier complet des codes postaux (y compris les codes spéciaux comme les codes militaires, concours et CEDEX), et on ne pouvait pas le republier. Mais est-ce encore le cas aujourd'hui ? _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
