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

[kimaidou]

bonjour Sly,
mes réponses plus bas :


Top super cool !


Merci ;)

>
> > 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


J'ai ajouté il y a environ 2 semaines le tag color dans cette page :
http://wiki.openstreetmap.org/wiki/FR:Relation:route#Transports_Publics

Pour le reste, j'aimerais bien avoir un tableau équivalent pour les
différents types d'arrêts.

>
> > 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 ;-) )


C'est pas vraiment plus "facile", juste plus dynamique : je n'ai pas à
ajouter à la main le style pour la ligne n° bidule de la ville machin. Dès
que le tag color est renseigné, c'est affiché !

>
> >     * 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


oui, comme pour ton beta.letuffe, mais je préfère le mode vectoriel : pas
besoin de refaire toutes les tuiles de tous les niveaux de zoom. Un seul
fichier vectoriel (assez léger) suffit

>
>
> >     * 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.


Je préfère me garder la possibilité d'afficher les tags des lignes sur clic
ou survol, pour voir ce qui est renseigné.


> 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


La limite se trouve surtout au niveau du navigateur. Firefox gère bien les
vectoriels en mémoire, mais IE 6 très mal, et ça peut ramer.

>
>
> > 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" ?


Le prob lème avec ce système de limitation par le zoom, c'est que de toute
manière le navigateur doit avoir tout en mémoire (et toute la France, ça va
tuer meme les machines les plus véloces). Avec le système de locations, on
libère la mémoire à chaque changement de location. C'est aussi pourquoi on
limite la taille maximale des locations

>
>
> 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 ?)
>

Au contraire, on utilise justement des requêtes postgis pour exporter les
vecteurs en fonctoin des locations
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20090702/0203037d/attachment.htm>