Le 19 septembre 2013 13:15, Pieren <pier...@gmail.com> a écrit : > 2013/9/19 Vincent de Château-Thierry <v...@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 !)
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
