heu.. je me suis relu, et j'ai l'impression d'avoir un ton un peu condescendant... Heu, pas du tout en fait, juste une petite frustration née de l'incompréhension. [?]
Le 9 juin 2009 13:19, kimaidou <kimai...@gmail.com> a écrit : > Merci Emilie et Sylvain pour vos remarques. > > Moi qui ai -un peu- l'habitude de concevoir et d'utiliser des bdd, je > trouve quand même que osm2pgsql va un peu trop loin dans la simplification. > Je trouve assez 'anti-bdd' : > * ne pas avoir de clé primaires (Qgis n'aime pas les couches Postgis sans > clé primaire) > * d'avoir 54 colonnes, pour la plupart du temps n'en remplir que 3 ou 4 > (merci l'optimisation) > > Je comprends que cela soit fait pour Mapnik, mais justement pour nos > histoires de relations on voit la limite : il y a déjà de la redondance dans > ma base postgis, et en plus il faut que je copie colle mes styles dans le > ficher de style xml de Mapnik pour gérer mes lignes de bus. > Est ce que vous auriez un lien qui montre comment utiliser / paramétrer > osm2pgsql ? Le wiki d'osm montre comment l'installer, mais je n'ai pas vu > plus de détail que dans la petite introduction ( > http://wiki.openstreetmap.org/wiki/Osm2pgsql ) > > Bref je vais essayer Osmosis pour voir ce qu'on peut faire avec. Ma > principale question : peut-on utiliser des données de osmosis depuis Mapnik > ? Il faudra sûrement modifier toutes les requêtes pour aller chercher les > bonnes géométries. > > A plus tard :D > > Le 9 juin 2009 13:07, Emilie Laffray <emilie.laff...@gmail.com> a écrit : > > Je confirme pour la difference entre osm2pgsql et Osmosis. osm2pgsql permet >> de faire certains precalculs et de nettoyer certaines informations, >> toutefois, on perd necessairement en information. Ce programme est vraiment >> fait pour permettre le rendu par Mapnik. >> Osmosis ne perd aucune information, toutefois, on arrive a un schema ou >> certaines tables n'ont pas de cles primaires. Certaines requetes prennent >> donc plus de temps et sont donc plus complexes. >> Il faut toutefois relativiser; Osmosis permet aussi de faire un tri avant >> l'insertion des donnees soit au niveau des nodes soit au niveau des ways. De >> plus, maintenant, Osmosis est capable de creer directement des geometries de >> type Linestring. >> Si on choisissait de faire une fusion des points dans Corine avant >> l'import dans OSM, il est plus facile de travailler avec le schema de >> Osmosis. C'est meme tres facile dans ce cas la de gerer la fusion des >> points. >> >> Emilie Laffray >> >> >> 2009/6/9 sly (sylvain letuffe) <sylv...@letuffe.org> >> >> On Tuesday 09 June 2009 11:38, kimaidou wrote: >>> >>> > J'ai regardé un peu, et en fait: >>> > * osm2pgsql n'importe pas tous les tags présents dans le fichier osm. >>> Par >>> > exemple, pas de colonne "operator", qui nous serait bien utile pour >>> > n'appliquer une couleur qu'à la ligne 15 (ref=15) de l'opérateur RATP >>> > (operator=RATP). >>> Change le fichier default.style >>> >>> >>> > * osm2pgsql fait 4 tables : une pour les points, une pour les >>> polygones, une >>> > pour les lignes, et une pour les "roads". Je ne sais pas bien si cette >>> > dernière enregistre les relations ou autre chose. Une idée ? >>> si polygone, prefix_polygon, si linéaire prefix_roads >>> (ça dépend donc des type de relation) >>> Je t'accorde que c'est une peu le bazar, il n'y aurait dû avoir que >>> point/ligne/surface >>> >>> >>> > Pour moi, cela est plutôt super limitant, car on perd la puissance du >>> couple >>> > tag=valeur de la bdd OSM. On perd des tags, notamment les tags color, >>> > operator, name de la relation, >>> A toi de dire à osm2pgsql de les importer. Il existe une autre solution >>> qui >>> est de créer un schéma avec osmosis à la place de osm2pgsql, qui, lui, >>> fait >>> de l'import .osm <=> postgis une équivalence >>> Mais j'ai cru comprendre que toute la force de osm2pgsql n'est pas de >>> garder >>> l'équivalence, mais de faire plein de pré-traitement pour accélérer les >>> choses dans une logique "temps réél" >>> >>> > et donc on ne peut pas styler en fonction de >>> > ces tags >>> Ce problème est sans rapport, cf plus loin >>> >>> >>> > Par contre, vu qu'on travaille avec Posgis, on pourrait limiter les >>> requêtes >>> > via des bouding box >>> Trop galère. >>> >>> > Le 9 juin 2009 11:24, Pierre Mauduit <pierre.maud...@gmail.com> a >>> écrit : >>> > > Une des limitations de mapnik, que j'ai découvert récemment en >>> tentant >>> > > un rendu perso du plan de métro RATP : Apparemment on ne peut pas >>> > > utiliser une colone de la base de données directement dans les >>> options >>> > > de style CSS de mapnik, et c'est bien dommage, >>> Petite rectification, mapnik (le moteur) n'est pas en cause, c'est le >>> module >>> de traitement des fichiers de config xml qui est en cause. Et en effet, >>> pour >>> l'instant, je n'ai pas réussi à changer le style dynamiquement en >>> fonction de >>> la base, j'ai dû faire comme toi : >>> >>> > > on est obligé de se faire >>> > > des fichiers XML hyper lourds qui filtrent en fonction du nom, de la >>> ref >>> > > ... pour déterminer de quelle ligne il s'agit et ainsi choisir la >>> bonne >>> > > couleur. >>> >>> Autant dire, que quand on va vouloir prendre en compte de tag color qui >>> est >>> 24bit, ça va faire un paquet de bloc style ;-) >>> >>> >>> > > Si quelqu'un a une autre technique afin d'utiliser les données en >>> base >>> > > directement dans les définitions des balises de style CSS je suis >>> preneur >>> Pareil, >>> il semblerait qu'utiliser l'API python puisse nous sortir d'affaire, mais >>> j'ai >>> pas fais assez de tests pour le confirmer >>> >>> >>> -- >>> sly >>> Sylvain Letuffe sylv...@letuffe.org >>> qui suis-je : http://slyserv.dyndns.org >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >
<<330.png>>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
