Les clés dans les extractions vers Postgres peuvent être réduites même sans réutiliser les tags dans OSM. Les requêtes faites dans les tables de features Postgres n'ont strictement rien à voir, les modèles de données sont complètement différents.
Très mauvais argument donc. C'est hors sujet et ne justifie en rien le fait d'avoir des tags clairement séparés dans OSM (même au prix d'une prétendue économie de stockage, si les tags surchargés deviennent ambigus, non seulement on complique les requêtes d'exportation, mais en plus elles commence à retourner des données qui n'ont rien à voir et ne devraient pas être importées dans Postgres. Postgres n'a aucune obligation d'utiliser les mêmes "clés" OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM. Le 9 juin 2013 15:06, Vincent Pottier <vpott...@gmail.com> a écrit : > Le 09/06/2013 13:08, Philippe Verdy a écrit : > > Le 8 juin 2013 16:05, Vincent de Château-Thierry <v...@laposte.net> a > écrit : > > >> Et en toute logique, il faudrait si on l'applique, le propager aussi aux >> boundary=administrative, à la place d'admin_level. >> > Tout à fait. > > > Certainement pas (ou à la limite seulement dans les relations > administratives (et qui ne sont QUE administratives et ne servent pas aussi > de limites pour autre chose). > L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations > multiples. Il se posera alors la question de savoir à quel autre tag > présent sur ce way correspond ce "level" car justement le "level" n'est PAS > orthogonal mais lié à un seul autre tag. > > C'est bien pour ça qu'on a un tag nommé "admin_level" (lié très > fortement à boundary=administrative pour lui apporter une sous-précision) > et qu'on a relevé un problème d'interprétation quant on l'a appliqué (à > tord) sur les frontières religieuses (qui n'ont rien de commun avec des > frontières administratives). > > ON, je en l’occurrence, l'ai appliqué après réflexion. > On, Sly en l’occurrence, avait repéré un problème sur layers.osm.fr et a > très bien réussi à le résoudre. > ON, toi en l’occurrence, ne semble pas avoir perçu comment Sly avait > résolu le problème sur layers.osm.fr > > > Franchement je ne comprend pas l'utilité même de vouloir unifier des > tags sous un même nom alors qu'ils ont des significations complètement > diférentes et ne sont pas liés aux mêmes données (et clairement pas > orthogonaux comme peuvent l'être "name", "url", "wikipedia", "natural", > "landuse" et "boundary"). > > Franchement je ne comprends pas l'utilité de multiplier les clefs alors > qu'une bonne logique booléenne résout les problèmes. > Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça permet > d'alléger les tables dans postgres. > Ça permet d’utiliser la logique plutôt que le bavardage. > > Il faudrait réfléchir plus sérieusement. > > Tout à fait. Tu peux t'y mettre. > > 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. > -- > 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
