<div dir="ltr">Désolé mais on ne parle visiblement pas de la même chose.<div><br><div>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).</div>
<div>Tout cela n'a rien à voir avec les tags d'OSM, j'insiste, c'est votre "cuisine" locale.</div><div><br></div><div>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.</div>
<div style><br></div><div style>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).</div>
<div style><br></div><div style>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.</div>
<div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 9 juin 2013 18:27, Christian Quest <span dir="ltr"><<a href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 9 juin 2013 17:47, Philippe Verdy <<a href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>> a écrit :<br>
<div class="im">> Toute la discussion portait sur les tables OSM qui n'ont pas de structure<br>
> (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est<br>
> ton script de traduction osm2pgsql qui va se tromper...)<br>
><br>
<br>
</div>La notion de "table OSM" n'a pas de sens... c'est ça que je voulais<br>
surtout faire passer comme idée, mais visiblement ça te dépasse peut<br>
être à cause d'un ancrage trop fort dans les notions GIS historiques.<br>
<div class="im"><br>
> Maintenant si ton problème est que tu mélanges tous les polygones<br>
> surfaciques dans ta base dans la même table, avec nécessité de créer une<br>
> colonne pour chaque tag distinct, et si ta base de données limite le nombre<br>
> de colonnes possibles par table, alors oui tu as un problème dans ta base,<br>
> mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout<br>
> autant séparer ces polygones pour avoir une base bien plus facile à<br>
> exploiter. Tu auras de toute façon autant de problème à distinguer les<br>
> objets importés de cette façon que dans les données OSM initiales, si tu as<br>
> mélangé les tags en en surchargeant certains pour des rôles différents.<br>
><br>
> C'est toi qui sur ta base prend la décision de faire ce schéma GIS<br>
> ultrasimplifié, réduit à pas grand chose d'utilisable.<br>
><br>
<br>
</div>Visiblement tu ne connais pas osm2pgsql, car c'est comme ça que cet<br>
outil (très largement utilisé faut-il le rappeler) fonctionne.<br>
Je n'ai fait aucun choix sur ce schéma.<br>
<div class="im"><br>
> Et même si tu mets tes polygones dans la même table (en fait uniquement pour<br>
> stoker la géométrie), ta base SQL peut encore stocker les tags par type de<br>
> feature dans des tables séparées. A mon avis c'est une des premières choses<br>
> que tu dois faire après cet import avant de pouvoir continuer, tu es amené à<br>
> grouper un certain nombre de polygones, chercher des équivalences, ou<br>
> ignorer certaines différences pour les unifier. Une partie de ce traval sera<br>
> fait dans ton script osm2pgsql modifié localement selon tes besoins, plutôt<br>
> que d'avoir à le faire après import dans ta base.<br>
><br>
<br>
</div>Aucune modification de script pour ma part. osm2pgsql est utilisé tel quel.<br>
<div class="im"><br>
<br>
> OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton<br>
> script osm2pgsql (dont il existe autant de versions que de moteurs de rendu<br>
> à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses.<br>
<br>
</div>Bon, c'est confirmé... pour combler tes lacunes sur osm2pgsql c'est<br>
ici que ça se passe: <a href="http://wiki.openstreetmap.org/wiki/Osm2pgsql" target="_blank">http://wiki.openstreetmap.org/wiki/Osm2pgsql</a><br>
<div class="im"><br>
<br>
> C'est toi qu iest entièrement responsable de ton schéma interne, qui ne nous<br>
> intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour<br>
> nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus<br>
> directement dans ta base issue de ta propre traduction).<br>
><br>
<br>
</div>Et pourtant... j'utilise les tags directement, étonnant non ?<br>
<br>
Les tags sont stockés en hstore (nommé "tags" avec une extrême<br>
originalité donc).<br>
Au cas où, voilà le lien pour te documenter :<br>
<a href="http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore" target="_blank">http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore</a><br>
<br>
Dans notre cas (vous vous souvenez, les académies), cela donnerai:<br>
<br>
SELECT way FROM planet_osm_polygon WHERE boundary='educational" AND<br>
tags->'boundary:level'=5;<br>
<br>
<br>
Dernier post sur le hors-sujet pour moi.<br>
<div class="HOEnZb"><div class="h5">--<br>
Christian Quest - OpenStreetMap France<br>
Un nouveau serveur pour OSM... <a href="http://donate.osm.org/server2013/" target="_blank">http://donate.osm.org/server2013/</a><br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>