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

Mar 9 Juin 11:19:44 UTC 2009

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/e74b90a8/attachment.htm>