[OSM-talk-fr] Obtenir la liste des communes de la CUB avec Overpass API ?

[Philippe Verdy]

Le 19 septembre 2013 13:15, Pieren <pieren3 at gmail.com> a écrit :

> 2013/9/19 Vincent de Château-Thierry <vdct at laposte.net>:
>
> > Ce constat reste encore valable pour quelques mois, tant qu'on n'aura
> > pas terminé le tracé complet des limites de communes.
>
>
> Si ça, ça ressemble pas à un appel à terminer les limites communales,
> je me fais moine ^^
>
> Ilya surtour que l'argumentcité est totalement faux, je dis bien
totalement car il s'agit de mauvaise foi manifeste car une énumération des
composantes filles d'une surface peut avoir lieu ***même si*** on n'a pas
encore tout tracé, et si on n'a pas la précision complète suffisante.

L'énumération des filles demande très peu de données dans la base : 1 seul
membre à ajouter par fille dans sa relation parente, donc en tout pour le
niveau adminstratif des communes, autant que de communes (alors que pour
les chemins membres des relation communales on monte facilement = une
moyene de l'ordre de 6 à 12 de membres par commune, et en tout de l'ordre
du quart de million de chemins membres pour les communes françaises.,
contre 36000 membres en tout pour les énumérations de communes filles
membres du niveau admin supérieur..). Cela fait très longtemps que ces
onnées auraient été terminées et de façon exhaustive et stable.

De plus l'opposition n'est absolument pas entre représentation des
frontières ou des surfaces car en fait en stockant des ways membres
uniquement on réalise les deux simultanément, les chemins membres étant
obligatoirement tous des anneaux fermés. Jamais il n'y a eu opposition
entre partisan du modèle surfacique et celui du modèle par frontière car
c'est exactement la même chose ici avec les mêmes données.

La différence n'est pas du tout entre surface et par frontières, mais entre
ces derniers (totalement équivalents entre eux) et la représentation
parsous-ensembles (qui n'est pas une représentation "relationnelle" non
plus, car un modèle "relationnel", au sens SQL du terme, ne peut pas
accepter les récursions d'un type d'objet vers lui-même : si on veut faire
une requête relationnelle, le système imposerait de dénormaliser ces
ensembles et sous-ensembles pour inclure dans le parent non seulement ses
filles,mais aussi ses petites filles et tous les niveaux descendants, ce
qui n'est absolument pas optimal ; ce type de requête nécessite un type de
requête SQL particulier, certes ,mais pas plus particulier ni plus
compliqué que les requêtes géométriques qui sont extrêmement fragiles et
très compliquées et lourdes à réaliser car il faut comparer non seulemetn
des listes de chemins membres très longues, mais aussi descendre jus'au
niveau de leurs noeuds et aire des calculs de projection sur un axe à
partir d'un point pour savori où se situe l'intérieur et l'extérieur et
déterminer s'il y a untersection ou non; la requête ne permettant pas non
plus de répondre quand une intersection existe mais n'est pas complète
d'une surface dans l'autre, car il y a un peu partout des anomalies
fréquentes avec des chemins oubliés oupas encore tracés non plus...).

Je ne dis pas qu'on doit utiliser le modèle ensembliste (relations membres)
à la place du modèle actuel surfaço-linéaire (utilisant des chemins
membres, ou bientôt des anneaux membres fermés avec l'introduction attendue
de la primitive 'surfacique" qui enfait va être une primitive d'anneaux
fermés), mais que les deux se complètent utilement et se renforcent
mutuellement pour permettre d'alléger de très nombreuses analyses et
exploitation des données. Le modèle ensembliste est en effet totalement
indépendant de la précision géométrique, il nécessaite très peu de données,
il est stable, documenté, facilement vérifiable et facile à garder stable
et complet. De plus il renforce énormément le système surfaço-linéaire en
évitant des tas d'accidents d'éditions (liés à l'oubli fréquent de
télécharger TOUTES les relations utilisant chaque noeud ou chemin donné
avant de le modifier).

Il suffit de voir comment très souvent les relations sont cassées en
France, et la difficulté constante pour les réparer (car cela demande de
télécharger énormément de données pour retrouver tous les chemins
nécessaires) ! En comparaison si on a une liste e filles dans la relation
parente, la réparation est évidente et ne nécessite pas de longues
recherches et très peu de données demandées au serveur. Tout est plus
efficace. pour naviguer dans les données. Regardez avec quelle faciliité
déconcertante on navigue en Espagne ou en Belgique et comment ces pays sont
TRES stables dans la base, le moindre accident étant très vite réparé et
facile à vérifier... Et même si on ne télécharge JAMAIS les remations
parentes, c'est le système qui s'en charge AUTOMATIQUEMENT partout (ce qui
n'est pas le cas avec le modèle surfaço-linéaire) : les oublis n'ont plsu
aucune excuse car cela ne peut provenir que 'd'une suppression volontaire
de données et non d'un accident lié à la fusion ou la scission d'un
chemin.en plusieurs.

Je voudrais donc qu'on arrêt d'opposer les deux modèles alors que selon les
usages, l'un sera nettement plus efficace que l'autre, et que les deux
modèles se renforcent mutuellement (mais ne sont pas équivalents entre eux,
justement en cas de données parcellaires, le cas des données manquantes
étant presque toujours du côté du modèle surfaço-linéaire actuel et presque
jamais du côté du modèle ensembliste !)
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130919/dbbb2e1e/attachment.htm>