Le 27 janvier 2012 02:34, Philippe Verdy <verd...@wanadoo.fr> a écrit :
> Le 26 janvier 2012 14:30, Hélène PETIT <h...@free.fr> a écrit :
>> Le 25/01/2012 18:52, sly (sylvain letuffe) a écrit :
>>>
>>> Tentons de rester objectif, et de mettre des "peut-être" quand ça reste
>>> une
>>> supposition plutôt que les superlatifs récemment lu du genre :
>>> C'est 10000 fois plus rapide.
>>
>>
>> Dans mon univers perso un sgbd est (10)mille fois plus rapide quand il fait
>> ce pour quoi il a été conçu au départ ; comme je préfère cartographier que
>> mettre la main dans le code (pour l'instant) je n'ai pas pris le temps
>> d'aller lire la descro du schéma de la base et de ses abatis.
>> Cela dit, quand je vois toute cette tonne de débats ne faisant (je crois ?
>> AC) pas particulièrement référence au schéma actuel de la base, je me
>> demande si j'ai des chances d'y comprendre quelque chose ; tout ça : à
>> vérifier, à confirmer ; et à relire le jour où j'aurais aussi pu comprendre
>> le système de catégories utilisé par le wiki :>(
>>
>> Pendant que j'y suis :
>> À quoi pourrait bien servir le tag "label" dans une relation "frontière
>> administrative" de niveau 8 ?
>
> Pour une commune dont la forme fait que son centroïde calculé tombe en
> dehors de ses frontières et le label par défaut semble indiquer le nom
> d'une autre commune. Regarde les boucles de la Seine dans le 92 pour
> comprendre...
Si on ne tague que la relation avec son nom, comme la relation n'a pas
de position bien définie pour le label, celui-ci sera par défaut
positionné sur le centroïde. La relation contient en général un
"admin_center" pour positionner son centre administratif (en principe
à la Mairie). Mais des communes ont des contours tels que la mairie
est très excentrée; bien que ce contour soit fortement convexe, le
centroïde marche bien en général pour le positionner, mais il peut y
avoir une position plus adaptée pour positionner le label sans
recouvrir d'autres éléments importants.
Le nom présent dans la relation peut aussi ne désigner qu'une partie
de la commune pour celles qui sont éclatées en plusieurs exclaves,
chacune pouvant avoir un nom distinct qu'il est plus adéquat
d'afficher sur la carte en tant que "lieu". La relation donne le nom
de la commune elle-même, pas celui de ses parties. Hors seule une de
ses parties contient un centre administratif (la mairie), l'autre
partie se retrouverait sans noeud membre "admin_center". Il faut alors
positionner un label même sans admin_center pour nommer cette partie
de façon visible sur la carte. Cependant ces parties définies dans des
relations séparées ne sont en principe pas ce qui définit la relation
de niveau 8, et pas forcément non plus un niveau 9 (arrondissement
communal) ou supérieur (quartiers, pôle de proximité). Pourtant il y a
bien une frontière admnistrative définie par cette relation à laquelle
on souhaite donner un nom distinctif sur la carte (en général un
toponyme géographique plus qu'un lieu "place")..
On a donc à régler ce genre de détails localement selon l'importance
qu'on donne à ces noms. Par défaut une relation communale sera
affichée avec le nom de la relation affiché le long de ses bordures
tracées, ou sinon positionné sur le centroïde. Si la résolution est
suffisante pour afficher un label à l'intérieur, le moteur cherchera à
utiliser la position de l'admin_center (cependant pas son nom car le
nom pourrait être celui du centre adminitratif tel que "Hôtel de
Ville", qui n'est pas suffisant pour nommer la commune sur la carte.
Il reste alors le label pour aussi donner le nom à afficher sur la
carte (qui lui apparait dans sa forme normale sans qualificatif de
désambiguation, car certaines relations éloignées les unes des autres
sont distinguées en ayant des noms qualifiés, facilitant les
recherches par nom... On ne voudrait pas voir par exemple "Paris
(Texas)" sur la carte du Texas, même si sa relation s'appelle ainsi,
on préfère avoir juste "Paris". Le rôle label est alors utilisé à la
fois pour positionner le label à afficher sur la carte, et ce qu'il
faut afficher.
Si un label est présent, il est préférable au nom et la position d'un
admin_center, et si ce dernier n'est pas présent non plus, par défaut
on utilise sur la carte dessinée le nom de la relation positionné sur
le centroïde de la relation. C'est comme ça que je vois les choses.
Note: l'IGN utilise des "centroïdes" modifiés : en général il est
positionné à la position du centroïde calculée, mais si cette position
tombe hors de toute zone habitée de la zone, il le modifie en la
position de la mairie sur l'entrée de son bâtiment principal. Parfois
il le mettra sur la place centrale ("Place de la Mairie", "Place de
l'Hôtel de Ville", dans les communes où la Mairie consiste en un
ensemble de bâtiments administratifs sans qu'on puisse déterminer
réellement lequel de ces bâtiments est le principal. si la mairie
officielle est en fait construite dans un hameau séparé de
l'agglomération principale (ça arrive dans les communes rurales), il
peut garder la position de l'ancienne mairie devenue annexe
administrative. Sinon il pourra utiliser la position considérée comme
centrale et traditionnelle par les habitants de cette agglomération.
D'autres cas concernent des communes issues de regroupement
d'anciennes communes (devenues de simples quartiers) : la mairie
officielle issue du regroupement peut très bien être dans la plus
petite agglomération.
Les règles sont assez floues, mais sont ajustées selon le feeling du
cartographe afin d'obtenir des cartes lisibles à ceux qui les
regardent. Cette position doit être utilisable aussi à toutes les
échelles (par exemple si les contours ne sont plus affichés mais
seulement un symbole avec un nom). On essaye d'éviter aussi de
superposer cette position avec une autre entité (une place, une rue),
afin de permettre aussi d'afficher son nom de façon séparée, s'il y a
encore de la place autour à l'échelle donnée. Le système donne un peut
de souplesse pour ces labels par rapport à un système de
positionnement automatique calculé.
Il y a aussi d'autres complications : pour ces différents objets,
"name" est le nom généralement utilisé, même par la commune elle-même
dans ses communications alors qu'elle a un autre nom officiel. On a
alors "alt_name" pour référencer le nom officiel même si ce n'est pas
celui qu'on affiche sur la carte. On a aussi "old_name" pour les
anciens noms, plus utilisés officiellement mais qu'on trouve encore
couramment (y compris dans les bases de données tierces (qui n'ont pas
d'autres moyens de rapprochement avec OSM tel que ref:INSEE donnant le
code INSEE de la commune). Et pour tous, on trouve aussi les
traductions avec un suffixe de code langue...
On peut trouver ausi des "ref:INSEE" associés aux anciennes communes
qui ont aujourd'hui disparu (issues d'une fusion), mais en général
l'INSEE conserve dans une scission de communes sa référence (code à 5
chiffres) pour la plus grosse nouvelle commune réduite ayant conservé
son nom (mais parfois une scission aboutit à deux communes ayant des
noms sans rapport avec l'ancien nom). Je me demande s'il faut ou non
garder les codes INSEE des anciennes communes qui ont fusionné dans
une autre et dont le statut en a fait de simples arrondissements
municipaux quartiers (niveau 9 ou plus), tant que cela ne donne pas
d'ambiguité, il me semble que l'INSEE conservera ces attributions de
numéros pour au moins un siècle (à cause des numéros d'identité des
personnes contenant les codes communes, et le fait que les registres
d'Etat-civil sont conservés et doivent pouvoir être retrouvés au moins
avec l'association de l'année).
Avec la multiplication des centenaires, des registres d'Etat-civil
restent ouverts bien plus longtemps qu'un siècle, et dans ce cas un
nouveau registre est utilisé pour les personnes en changeant le
premier chiffre de leur numéro d'identité: au lieu de 1 et 2 pour
hommes et femmes, on trouvera certaines années 3 et 4 pour le nouveau
siècle tant que le registre ouvert pour l'année du siècle passé
contient des personnes vivantes; l'INSEE ne le fait pas toujours si
les numéros de séquences à 3 chiffres à la fin du numéro d'identité
sont loin d'être dépassés : bien que ces registres d'années de
naissance différentes restent séparés, celui du nouveau siècle peut
démarrer ses numéros de séquence des personnes à trois chiffres sans
commencer par 001, et dans ce cas pas besoin de codes INSEE différents
pour la commune.
Dans les villes très peuplées toutefois il arrive que 1000 numéros par
sexe et par année ne suffisent pas, et la commune a des registres
d'Etat-civil qui utilisent des numéros supplémentaires qui ne
correspondent pas à un code commune officiel ; l'association des codes
supplémentaires de registres d'Etat-vil peut être quasi-permanente (il
peut ne pas être utilisé certaines années mais l'attribution reste sur
une période très longue) ou occasionnelle pour certaines années, mais
la commune elle-même n'a qu'un seul code pour la désigner
administrativement et géographiquement.
Tout cela complique un peu les choses. Au plan légal (pour la
comptabilité publique des collectivités territoriales), de plus en
plus ce sont les codes SIREN qui sont utilisés (qui reprennent des
parties du code INSEE mais ajoutent des numéros unique distinctifs
permettant de distinguer les communes qui ont changé de statut légal,
ou issues d'une fusion ou scission, ce code SIREN unique ne dépendant
plus de l'année (la commune ajoutera des SIRET pour ses différents
établissements ayant des comptabilités séparées, ou pour ses
arrondissements municipaux qui ont une comptabilité propre, comme
toute autre personne morale tenue de tenir une comptabilité légale
pour ses établissements; les EPCI ont leur propres SIREN et SIRET en
tant que personnes morales séparées).
De même que la Préfecture ou sous-préfecture ayant son siège dans la
commune, ou les Conseils généraux et régionaux des départements et
régions auront leur propres SIREN, mais l'ennui est qu'on met dans le
département, l'arrondissement comme "admin_center" le même noeud que
le l'admin_center de la commune. Le SIREN est alors faux, même si les
noms attribués sont homonymes.
En théorie cela devrait être des noeuds distincts pour leurs
admin_center respectif. Il vaut donc mieux ne pas taguer les SIREN sur
les noeuds (admin_center ou label) mais sur les relations de chaque
entité. Mais quel code SIREN indiquer pour le département ou la
région: celui de la collectivité territoriale (conseil général ou
régional selon le niveau), ou celui de la préfecture (de département
ou de région selon le niveau) ? Il me semble qu'on a privilégié les
collectivités territoriales (conseils généraux ou régionaux), puisque
les préfectures elles-mêmes sont de compétence de l'Etat et non
réellement locales et autonomes (ces préfectures ou haut-commissariats
ne sont que des établissements de l'Etat en tant que même personne
morale, attachés directement au Ministère de l'Intérieur ou au
Ministère de l'Outre-mer). Il reste à savoir où positionner ces
conseils généraux et régionaux (pas à la Mairie...).
Que faire alors aussi de la "capitale" du pays (la commune,
collectivité unique pour le département et assimilée au conseil
général, a son siège à l'Hôtel de Ville, mais pas l'Île-de-France qui
a son propre conseil régional ailleurs, et la France en tant qu'Etat
n'a ses institutions dans aucun des deux lieux et pas de position
précise : on l'a positionné sur une zone presque vide de l'ïle de la
Cité, et on a donc au moins deux noeuds à libeller "Paris", ou alors
on labelle distinctivement à l'Hôtel de ville "Ville de Paris" pour la
collectivité territoriale unique (niveaux 6/7/8), les deux labels
pouvant s'afficher sur la même carte à des positions proches mais pas
identiques, ou bien on positionne l'admin_center des niveaux 6/7/8 à
l'hôtel de ville, mais on utilise partout comme "label" (à afficher
comme "Paris") la position "virtuelle" actuelle à l'extrémité de l'Île
de la Cité sur une place vide (différente aussi de la position de la
Mairie du 1er arrondissement au niveau 9) afin de ne faire apparaître
sur la carte qu'un seul label "Paris".
Tout ça peut se discuter, le but étant tout de même de n'entraîner
aucune ambiguïté pour les recherches de lieux ou d'entités par un
moteur, ni pour la consultation des cartes dessinées...
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
