Enfin tu commences à comprendre ! Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue d'un export et d'une traduction avec osm2pgsql (ou autre chose) vers une base GIS.
Toute la discussion portait sur les tables OSM qui n'ont pas de structure (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est ton script de traduction osm2pgsql qui va se tromper...) Maintenant si ton problème est que tu mélanges tous les polygones surfaciques dans ta base dans la même table, avec nécessité de créer une colonne pour chaque tag distinct, et si ta base de données limite le nombre de colonnes possibles par table, alors oui tu as un problème dans ta base, mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout autant séparer ces polygones pour avoir une base bien plus facile à exploiter. Tu auras de toute façon autant de problème à distinguer les objets importés de cette façon que dans les données OSM initiales, si tu as mélangé les tags en en surchargeant certains pour des rôles différents. C'est toi qui sur ta base prend la décision de faire ce schéma GIS ultrasimplifié, réduit à pas grand chose d'utilisable. Et même si tu mets tes polygones dans la même table (en fait uniquement pour stoker la géométrie), ta base SQL peut encore stocker les tags par type de feature dans des tables séparées. A mon avis c'est une des premières choses que tu dois faire après cet import avant de pouvoir continuer, tu es amené à grouper un certain nombre de polygones, chercher des équivalences, ou ignorer certaines différences pour les unifier. Une partie de ce traval sera fait dans ton script osm2pgsql modifié localement selon tes besoins, plutôt que d'avoir à le faire après import dans ta base. OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton script osm2pgsql (dont il existe autant de versions que de moteurs de rendu à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses. C'est toi qu iest entièrement responsable de ton schéma interne, qui ne nous intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus directement dans ta base issue de ta propre traduction). Le 9 juin 2013 17:28, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Le 9 juin 2013 16:18, Philippe Verdy <verd...@wanadoo.fr> a écrit : > > Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des > > compétences en bases de données (c'est aussi mon boulot, me^me si ça ne > vous > > semble pas évident) ne feignez pas de rien comprendre. > > > > OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer > seulement > > noeuds, chemins et relations, plus des tables annexes pour les membres de > > relation), et les 3 tables utilisent une table unique pour tous les tags > > (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce > qu'on > > voit dans les requêtes XML de son API et rien de plus. > > > > Le schéma de la base utilisé par l'API est destiné à un unique usage: > le fonctionnement de l'API d'édition. > Ce schéma ne tire même pas partie de PostGIS car cela ne lui servirai > à pas grand chose. > > Ce schéma n'a donc aucun rapport avec l'usage qu'on peut faire des > données. C'est d'ailleurs ce que j'explique souvent: les données OSM > n'ont pas de structure prédéterminée autre que sémantique, on est dans > une logique NoSQL et en fonction de l'usage qu'on veut en faire > (rendu, géocodage, routage, etc) on va les structurer de telle ou > telle façon (d'où des schémas différents proposés par osm2pgsql, > osmosis ou imposm). > > > Tes propos, bien que paraissant cohérents, sont purement théoriques et > ne reposent visiblement sur aucune expérience pratique. > > Pour faire un rendu avec un schéma osm2pgsql, on utilise seulement 3 > tables: > - une pour les objets ponctuels, > - une pour les objets linéaires, > - une pour les objets surfaciques. > > Contrairement à ce que tu crois, routes, voies ferrées, lignes > électriques sont dans une seule et même table: planet_osm_line > Les polygones de découpages admin (donc les villes), les landuse (donc > les forêts), les terrains de sports sont dans la table > planet_osm_polygon > > Philippe, si tu pouvais prendre le temps de te renseigner sérieusement > ça ferai gagner du temps à pas mal de monde: > - ceux qui lisent et qui savent et qui vont perdre du temps à corriger > tes affirmations, > - ceux qui lisent et ne savent pas qu'il faut prendre avec des > pincettes tes affirmations (l'unique raison qui fait que je lis encore > tes messages et que j'y réponds). > > -- > Christian Quest - OpenStreetMap France > Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ > > _______________________________________________ > 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
