[OSM-talk-fr] Lignes de bus, besoin d'aide

Mar 9 Juin 11:21:27 UTC 2009

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 <kimaidou at 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.laffray at 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) <sylvain at 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.mauduit at 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 sylvain at letuffe.org
>>> qui suis-je : http://slyserv.dyndns.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20090609/7222dd34/attachment.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: 330.png
Type: image/png
Taille: 611 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20090609/7222dd34/attachment.png>