Désolé mais on ne parle visiblement pas de la même chose. Pas la peine d'accuser l'autre de ses "lacunes" puisque dès le départ vous avez confondu (avec insistance en plus, ce qui est pourtant faux !) la base OSM avec vos bases Pgsql traduites par un script spécifique (tuné en fonction de Mapnik le plus souvent). Tout cela n'a rien à voir avec les tags d'OSM, j'insiste, c'est votre "cuisine" locale.
Et même si vous conservez les tags dans un "hstore" vous aurez les mêmes ambiguités à résoudre si elles ne sont pas résolues dès le départ dans la base OSM (non structurée). Ce hstore en passant n'a aucune problème à garder les tags OSM originaux, puisqu'en fait votre base ne l'utilise que comme source de métafonnées annexes, dans un vrac aussi informe que la bae OSM d'origine. Personnellement je n'utilise pas du tout Mapnik (en fait je ne fais que visualiser des rendus effectués par d'autres, mais ce n'est pas les seuls rendus que je visualise) ce n'est pas mon problème et je n'en ai absolument pas besoin (et plein de monde utilisant les données d'OSM n'en a pas besoin non plus et n'est pas gêné par les restrictions ou insuffisances ou limitations de Mapnik). Et je ne vois pas pourquoi OSM devrait être contraint par ce que sait (ou ne sait pas) faire Mapnik. Bien au contraire, si on est plus précis dans la base OSM, c'est Mapnik qui aura moins de difficultés à interpréter les résultats puisqu'il n'aura plus d'ambiguités. Le 9 juin 2013 18:27, Christian Quest <cqu...@openstreetmap.fr> a écrit : > 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 >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
