Le 24 janvier 2012 11:51, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > On mardi 24 janvier 2012, verdy_p wrote: >> > Pour verdy_p : toutes les utilisations que tu as cités peuvent déjà se >> > faire avec le modèle actuel (modèle frontières) grâce aux bases de >> données >> > relationnelles. > > Je me suis trompé, je voulais dire "grâce aux bases de données spatiales" > >> Pas du tout ! Pour trouver ces relations de subdivision, ce ne sont pas >> du >> tout des modélisations de type relationnel, mais de type géométrique (2D >> uniquement ! avec les limites que cela comporte quand on passe à la 3e >> dimension sur les plans multicouches, par exemple si on veut modéliser >> les >> étages de la gare Montparnasse, avec une incertitude sur les élévations >> sachant qu'il y a des couloirs en pente aussi !). > > Je ne comprends pas le rapport avec la gare Montparnasse, on parle ici > d'entité administrative. > (Et au pire, les bases de données spatiales, comme l'indique le nom, > peuvent > aussi trouver dans volume appartient un point 3D) > >> Par exemple trouve la relation qui lie le 1er arrondissement de Paris >> (niveau 9) avec la commune de Paris (niveau 8). > > Ça se fait, ça tient en une ligne de SQL avec postgresql et la base > osm2pgsql, > je peux d'ailleurs faire pareil pour trouver que le 1er arrondissement de > Paris est en europe, en france, en Ile de france, etc. > > En revanche, dans le modèle complètement relationnel que tu proposes, pour > faire la même chose, tu sera obligé de passer niveau après niveau, puisque > l'arrondissement de Paris n'est pas en subarea de l'europe. > > Je le répète, les deux modèles permettent la même chose, il me semble > juste > une perte de temps d'utiliser les deux. > En plus, comme l'espagne les utilises, attendons 3 ans, et nous leur > demanderons si c'est mieux ou moins bien ! > >> C'est un gâchis énorme de requêtes SQL. Et oui cela ne facilite pas du >> tout >> le travail sur la carte et ses mises à jour. Et produire des cartes >> statistiques par exemple est un enfer sans les "subareas". > > Tentons de ne pas tout mélanger : > 1- Il y a le boulot pour les ordinateurs > 2- Et le boulot pour les humains > > Je privilégie de loin la réduction de 2), si 1) devient intenable, ce qui > n'est pas le cas, nous repenserons 2)
Justement, le 1) est intenable, et produit dix mille fois trop d'erreurs. C'est un enfer à maintenir de façon cohérente et cela entraine une redondance énorme en nombre de membres à copier de relation en relation, et des requêtes géométriques très couteuses, là ou les requêtes relationnelles sont bien plus efficaces. Ne pas oublier non plus que les cartes ne seront pas toujours utilisées avec des moteurs disposant de requêtes spaciales. De plus tu supposes que les sous-zones forment une partition d'une zone principale, ce qui n'est PAS toujours le cas (il y a des "trous" volontaires dans les sous-zones, et parfois des sous-zones à cheval sur deux zones de niveau supérieur, et le modèle géomatrique ne permet pas de représenter ça). Donc j'insiste bien que la géométrie n'a de sens que pour définir une zone toute seule (son contour et la surface qu'elle englobe) indépendamment de ce qu'elle peut couvrir. Les sous-zones ne sont pas liées par une règle de partition stricte, c'est une relation différente, non spaciale mais bien relationnelle. Regarde l'exemple que j'ai fait sur Paris pour les arrondissements: aucune redondance, et une grande facilité de navigation et d'exploitation pour créer des cartes statistiques sans faire aucune requête spaciale (par exemple pour faire des agrégats statistiques de population, sans doubles comptes, et pourtant exhaustives). Les deux infos ne sont pas *nécessairement* redondantes et doivent aussi permettre de faciliter le contrôle de cohérence. On met moins de membres dans les relations (les boundary segments pour les contours partagés avec les zones voisines, et les subarea pour les sous-zones contenues, dont on peut vérifier qu'elles ne débordent pas de la zone mère et qu'elles forment bien une partition (les exceptions à ces deux règles existent mais sont bien plus faciles à gérer). L'édition est aussi facilitée puisque les membres inclus sont bien plus localisés, on n'a plus à gérer des listes de centaines de membres difficiles à contrôler et trier pour vérifier qu'ils sont bien continus ou complets. L'éditeur n'a plus à charger et sauvegarder autant de données (des dizaines de milliers de noeuds dès qu'on modifie une limite en bordure de région, bien plus en core si on est en frontière de pays, car les différents types de frontières s'y superposent... Et on évite les erreurs constantes du serveur qui peine à afficher l'historique, et retourne souvent "data full"... -- View this message in context: http://gis.638310.n2.nabble.com/Reflexions-sur-la-modelisation-dans-osm-des-niveaux-administratifs-en-france-tp7216522p7221023.html Sent from the France mailing list archive at Nabble.com. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
