Le 9 juin 2013 17:47, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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...) >
La notion de "table OSM" n'a pas de sens... c'est ça que je voulais surtout faire passer comme idée, mais visiblement ça te dépasse peut être à cause d'un ancrage trop fort dans les notions GIS historiques. > 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. > Visiblement tu ne connais pas osm2pgsql, car c'est comme ça que cet outil (très largement utilisé faut-il le rappeler) fonctionne. Je n'ai fait aucun choix sur ce schéma. > 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. > Aucune modification de script pour ma part. osm2pgsql est utilisé tel quel. > 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. Bon, c'est confirmé... pour combler tes lacunes sur osm2pgsql c'est ici que ça se passe: http://wiki.openstreetmap.org/wiki/Osm2pgsql > 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). > Et pourtant... j'utilise les tags directement, étonnant non ? Les tags sont stockés en hstore (nommé "tags" avec une extrême originalité donc). Au cas où, voilà le lien pour te documenter : http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore Dans notre cas (vous vous souvenez, les académies), cela donnerai: SELECT way FROM planet_osm_polygon WHERE boundary='educational" AND tags->'boundary:level'=5; Dernier post sur le hors-sujet pour moi. -- 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
