Justement oui, mais tu ne parles pas là du tout de la base OSM elle-même !
Ta base "osm2psql" n'a rien à voir, c'est le résultat d'un import avec un script de conversion ecrit en C qui effectue des sous-selection compliquées pour traduire le schéma OSM en features importés dans ta base. Bref tu fais encore semblant de ne pas comprendre que les deux bases n'ont absolument rien à voir entre elles, les tables n'ont pas du tout le même structure, et là vous êtres en train de décider quelquechose pour la base OSM (les noms des tags), alors que ces tags sont totalement inexistants dans ta requête donnée en exemple (ta requête contient juste des noms de colonnes dans une table de feature appelée "france_polygon"). Le 9 juin 2013 16:50, Vincent Pottier <vpott...@gmail.com> a écrit : > Le 09/06/2013 15:41, Philippe Verdy a écrit : > > > > > Le 9 juin 2013 15:06, Vincent Pottier <vpott...@gmail.com> a écrit : > >> Il faudrait réfléchir plus sérieusement. >> >> Tout à fait. Tu peux t'y mettre. >> > > Commence par te l'appliquer à toi-même. > > Merci, c'est fait. > > quand tu comprendras que la base OSM pour l'instant n'est pas > structurée du tout comme une base GIS et que son modèle de données ne > permet pas des distinctions aussi claires. Le seul moyen avec le modèle OSM > plat de simuler les tables de features d'une base GIS c'est d'utiliser des > conventions de préfixes pour nommer les tags (le préfixe deventant > l'équivalent du nom de la table de feature externe, dans laquelle tu ne > mélanges pas les choix et les carottes même si ce sont des légumes). > > >> Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser >> des mêmes clefs secondaires conjointement avec des clefs primaires >> différentes : produce, operator... orthogonaux ou pas. >> > > On en reparlera le jour où OSM commencera à supporter dans sa base > directement des tables de features et pas seulement des objets > indifférenciés, avec aussi l'intégration des schémas de données. Pour > l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons > propre et évitons de tout mélanger (c'est déjà assez compliqué d'interroger > la base OSM justement faute du moindre modèle de données). > > As-tu déjà essayé sur une base osm2psql quelque chose du genre : > SELECT > name, > way > FROM > france_polygon > WHERE > boundary='administrative' > AND > admin_level='8' > > Si oui, alors on en reparlera... > -- > FrViPofm > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
