On Tuesday 09 June 2009 11:46, Pierre Mauduit wrote:
> Salut,
>
> >
> > 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, et donc on ne peut pas styler en
> > fonction de ces tags
> >
> Il est possible de recompiler / tweaker osm2pgsql vu que Sylvain le fait
> sur Beta pour conserver je ne sais plus quel champ. Mais le tag color
> dans les relations de lignes de transport en commun est-il répandu ? Il
> ne m'a pas semblé le voir sur le wiki.
Même pas de recompilation, juste le fichier de style de osm2pgsql
J'en ai eu besoin pour des trucs codés en dur ou pour obtenir autre chose que
des tag : genre user, date de dernière modification
> Ou alors cela me démange depuis quelques jours d'ouvrir un ticket sur le
> trac de mapnik avec comme feature request utiliser les données de la
> base directement dans le style CSS.
ça, ça me semble mieux comme solution. Pas sûr que ça soit possible ni que
quelqu'un le fasse (et mon niveau en c++ est trop lamentable)
L'autre solution qui marcherait avec l'existant serait de définir une palette
de couleur pour le tag color :
red, green,.... (genre 20 max)
et d'écrire un style cra-cra du genre :
<Style name="Bus">
<Rule>
<Filter>[color] = 'red'</Filter>
<LineSymbolizer>
<CssParameter name="stroke-width">5</CssParameter>
<CssParameter name="stroke">#FF0000</CssParameter>
</LineSymbolizer>
</Rule>
<Rule>
<Filter>[name] = 'green'</Filter>
<LineSymbolizer>
<CssParameter name="stroke-width">5</CssParameter>
<CssParameter name="stroke">#00FF00</CssParameter>
</LineSymbolizer>
</Rule>
...
> intéret à le garder dans la table. Ainsi la "limitation" des colones de
> la base après conversion dans le postgres est une nécessité.
Mon léger regret sur cette histoire de tag/osm2pgsql c'est cette idée tordu du
nombre de colonne statique. Un lien relationnel aurait pu être jouable et
avoir une table des tag
way 1---->N---->N---->1 TAG
ça reste un choix que je peux comprendre, style plus simple à écrire, 2
opérations de jointure de moins. Mais le gain en temps de calcul me semble
perdu par la présence de centaines de Mo sur disque juste pour stocker la
chaîne "highway"
> Pour la structure, de la base en elle-même, je pense qu'elle est
> relativement "plate", (pas vraiment de relations entre les tables)
Aucune même
> soupçonne d'ailleurs qu'il y ait duplication des données (les relations
> lignes de bus contiennent la description de routes deja présentes en
> base, mais je pense pas que l'on ait le choix).
Et pas que ça ;-)
--
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
