[OSM-talk-fr] OsmTransport : outil dynamique de suivi des réseaux de transports public

[sly (sylvain letuffe)]

> Suite aux évolutions de l'application de suivi des transports publics
> "OsmTransport" que j'avais commencé à développer, je vous transmets la
> présentation détaillée qui est disponible, avec des copies d'écran ici :
> 
http://3liz.com/blog/rldhont/index.php/2009/07/02/280-osmtransport-application-de-suivi-des-reseaux-de-transports-publiques

Top super cool !

Mais comme je ne poste jamais "que" pour dire bravo ;-) (honte sur moi !) :

> mises en forme en fonction du type de ligne et de la couleur spécifiée dans
> la relation route par le tag "color". 
Ce serait possible de documenter ces usages (de color et de ? network ? tram ? 
bus ?) sur le wiki ? (comment taguer, dans quel cas est-ce possible, à quoi 
cela s'applique) 
Histoire d'éviter que d'autres dans leur coin se lancent sur cette voie avec 
un tag color=red/route_color=0xRGB

> Les principaux avantages de
> l'utilisation de l'affichage vectorielles par rapport à l'utilisation de
> Mapnik pour afficher ces lignes sont :
C'est plus facile mais ça ram ? (je fais un pronostic avant lecture ;-) )

>     * l'utilisation dynamique du tag "color" pour styliser chaque ligne (pas
> besoin de créer autant de styles que de lignes ce qui nécessaire dans
> Mapnik). Une ligne dont la route n'a pas de tag "color" est affichée en
> noir.
Bonne remarque, cette fonction manque au style de mapnik et c'est dommage

>     * la possibilité d'afficher ou non chacune des couches, si on ne
> souhaite par exemple que voir les lignes de métro.
En supposant que tu fasses 3 layers mapnik : bus/tram/metro, ça doit rester 
jouable

>     * la possibilité d'avoir des informations complémentaires sur un arrêt
> (ou un ligne) sur clic de l'élément. 
je pense que ça n'empêche pas, tu gardes ton codes JS actuel, mais tu ne fais 
plus de rendu des traits, tu gardes juste la fonction d'info bulle sur un 
point.

Mais je conçois parfaitement que votre solution soit préférable pour plein de 
bonnes raisons, je crains juste le résultat pour des grosses villes (+ 
transport péri-urbain) avec bus/tram/metro

> avec le nombre d'éléments à afficher par le navigateur. C'est pouquoi le
> choix a été fait de créer des zones nommées "locations" pour lesquelles les
> lignes sont extraites. 

Ha ? c'est pénible ça pour la "scalabilité" ça veut dire que chacun doit 
passer pour créer "sa zone" qu'il va falloir gérer ceux qui n'ont pas fait 
une "bonne zone"
> (seules les lignes de cette zone
> sont affichées, pour ne pas surcharger le navigateur).

C'est peut-être une idée à la con, mais :
Il est rare qu'un gus veuille afficher les réseaux de bus de la france entière 
non ? ne serait-ce pas souhaitable de limiter le zoom minimum d'activation du 
layer ? Et ainsi s'affranchir de cette gestion pénible de "choix de zone" ?

Une zone étant finalement définie par ce que regarde l'utilisateur.

(Ou alors je flaire que vous n'avez pas trouvé la requête postgis "qui va 
bien" ;-) un coup de main ?)

-- 
sly
Sylvain Letuffe sylvain at letuffe.org
qui suis-je : http://slyserv.dyndns.org