> un numéro unique comme pour les bugtrackers avec une url qui pointe > dessus permettrait de suivre un bug
Ah oui. Indispensable.... Au même titre que pouvoir spécifier des coordonnées dans l'URL afin de ne pas tomber à chaque fois sur la magnifique ville de Rennes :-) > Je veux rapporter une erreur concernant un [bâtiment/rue/nom/point > d'intérêt/zone/autre(précisez)] J'y ai réfléchi, mais est-ce vraiment utile ? Quid des doubles-classifications ? Peut-on être exhaustif ? Faut-il une hiérarchisation ? etc. Un système de tags... avec toutes les discussions passionnantes que ça engendre ;-) Trop formaliser tue la créativité. > Faire apparaître les FIXME/TODO me paraît indispensable J'ai pas compris. > Le bouton pour ajouter un report ne saute pas assez aux yeux Oui. J'en sue avec le placement de ce bouton. Je n'ai pas d'idée miracle. > FF3RC1 (Kubuntu - KDE4.1b) ne fonctionne pas , ni sous Konqueror > KDE4 Si ça ne fonctionne pas sur FF3 c'est particulièrement gênant, sachant que dans 5 jours, 90% de la population d'OSM tournera dessus ;-) > Je ne trouve pas le lien avec GoogleAppEngine ou alors c'est au > niveau du serveur Oui. GoogleAppEngine est : - un hébergement limité mais gratuit - un framework original (Python + BigTable) Donc, côté utilisateur, que ce soit là dessus où sur un LAMP classique, ça ne change rien. > le côté "pas d'authentification" me chagrinne. Ma philosophie c'est : - OSM = données clean = authentification - OpenStreetBugs = données brouillon = pas d'authentification Ça ne sert à rien de faire un truc sécurisé et complexe si c'est pour faire moins bien que Potlatch. Et pour te rassurer un peu... 1. OSB est indélébile. Ce qui y est écrit reste tel quel. Par contre il est possible pour n'importe qui d'ajouter autant de compléments d'information que nécessaire. 2. Pour l'instant, aucune donnée n'est réellement supprimée (quand vous faites "del", les données deviennent justes inaccessibles). Il est donc techniquement possible de récupérer les données perdues. Je dis "pour l'instant", car GoogleAppEngine (version gratuite) limite la base de données à 500Mo... > tu devrait presenter l'url sur la liste anglaise. Oui. Je vais peut-être corriger un ou deux bugs avant. >> La base de données, c'est BigTable > ça me donne envie de m'y mettre aussi Si tu aimes les tables de hachage, les listes chaînées, les arbres binaires... c'est chouette. > Il y a tout de même un problème, qui n'apparait pas pour l'instant > vu le faible nombre de POIs, mais qui ne tardera pas à pointer le > bout de son nez dès que leur nombre sera conséquent (qqs centaines) > : tous sont chargés au démarrage de l'application. Non. Seuls les points visibles sont chargés ; les autres sont chargés en AJAX au fur et à mesure qu'on fait glisser la carte. Lorsqu'on dézoome trop, les points ne sont pas non plus chargés (ceux qu'on voit sont ceux qui ont déjà été chargés). > Ce qui risque de ralentir bcp leur chargement à terme. Un remède : > n'afficher que ceux qui sont présents dans l'étendue courante de la > carte et limiter ce nombre à 100 (par exemple). J'ai déjà limité (120 pois max par requête). Par contre je n'ai pas fait de garbage collector : une fois les points chargés, ils sont chargés. Donc s'il on joue trop longtemps avec OSB, ça risque de ramer. >> Yaurai moyen d'avoir le code source ? ou d'ajouter des >> développeurs sur le projet AppEngine ? > Je plussoie la demande ;-) J'y pense :-) Mais le code n'a rien de spectaculaire et n'est pas super clean. - 90% du code est côté client (script.js) - 10% du code est côté serveur (python) Xav _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr